Three orthogonal layers, each with five levels from L1 (novice) to L5 (sets the standard). Every level pairs a behavioral descriptor (what the work looks like) with the evidence that supports it. At L4 and L5, evidence splits into two channels: Git-visible signals and Peer-attested observations. Nothing here is hidden in product code — if your credential says L4, this is the bar it was held to.
Skills every engineer needs regardless of stack. Assessed primarily from public GitHub artifacts, with peer attestation supplying the L4/L5 evidence code alone can’t show.
Writing code that is correct, readable, and survives contact with other humans (including future-you).
Writes code that compiles and passes the happy path. Glaring bugs sit in main flows; edge cases not considered. Copies patterns from tutorials without understanding why.
PRs with frequent style-fix follow-ups; commits labeled 'fix typo' / 'fix bug' on own recent work.
Writes code that follows the team's stated conventions when reminded. Reaches for the first working solution; rarely refactors. Reads existing code to copy patterns.
PRs are accepted but reviewers leave 5+ structural comments; uses linter only when CI fails.
Writes code that is idiomatic for the language and consistent with the codebase. Names things well. Refactors locally when seams become obvious. Considers edge cases unprompted.
PRs land in ≤2 review rounds; reviewers comment on logic, not formatting. Self-merges minor changes without rework.
Writes code that other engineers learn from. Anticipates how the code will be modified next quarter. Refactors strategically — knows when to leave duplication alone. Pushes back on 'clever' code when 'boring' works.
Git-visible: frequently the original author of files others fork or extend; high PR merge rate with few revision rounds; sustained commit activity across multiple repos. Peer-attested: other engineers say they learn from this person's code; cited in review as a model to follow.
Sets the codebase's taste. Designs APIs that are hard to misuse. Recognizes when an entire abstraction is wrong and proposes a credible replacement path.
Git-visible: owns repos with high star/fork counts that others depend on and extend; broad authored footprint across repos and orgs; sustained multi-year maintenance visible in commit history. Peer-attested: sets the codebase's taste; their style and PR comments are treated as norms; referenced in design docs.
Turning 'it doesn't work' into a fix, by reducing problems to their smallest reproducible form.
Reads stack traces for keywords; tries random fixes until something passes. Asks for help without isolating the failure.
Issue comments like 'doesn't work, can someone look' with no reproduction. Pairs frequently to debug their own code.
Can isolate which file/function is failing with prompting. Uses print statements and a debugger when shown how. Forms one hypothesis at a time.
Bug reports include a stack trace but no minimal repro. Fixes the symptom; the cause sometimes returns.
Forms competing hypotheses and disproves them methodically. Reads upstream library source when needed. Writes a failing test before fixing.
Bug PRs include a regression test. Triage notes show 'tried X, ruled out by Y.' Doesn't flail.
Debugs across system boundaries — finds that the 'frontend bug' is a CDN cache. Builds intuition for where bugs live in this codebase. Reduces complex failures to minimal repros that fit in a Slack message.
Git-visible: PRs frequently reference cross-cutting root causes rather than surface symptoms; authored commits show systematic debugging patterns (bisect, instrumentation, test-first) across multiple repos. Peer-attested: the team's go-to for cross-boundary bugs; teammates bring their gnarliest failures to this person.
Predicts failure modes before they happen. Diagnoses production incidents from telemetry patterns alone. Knows when not to debug (when to roll back, when to escalate).
Git-visible: authored repos with CI/observability tooling; sustained multi-year contribution history showing reliability-focused work; cross-repo authored activity spanning infrastructure and application layers. Peer-attested: diagnoses production incidents from telemetry alone; predicts failure modes during design review.
Choosing how the pieces fit together — and what they're allowed to assume about each other.
Designs are implicit in the code; doesn't think about components vs interfaces. Couples concerns freely.
One-file solutions; no design discussion before coding.
Can sketch a component diagram for a small feature when asked. Recognizes when to put logic in a function vs. inline. Follows team's architecture patterns when reminded.
Drawings on whiteboards mirror what's already in the codebase. Reaches for inheritance when composition would do (or vice versa).
Designs medium features end-to-end. Identifies the right boundaries (data, transactions, deploy units). Knows the common patterns (CRUD, pub/sub, request/response, queue/worker) and picks reasonably.
Writes design docs for >1 week features. Reviewers ask clarifying questions, not 'what?' questions.
Designs systems with explicit non-functional requirements (latency, durability, blast radius). Identifies and evaluates trade-offs in writing. Designs for failure, not just success.
Git-visible: PRs and READMEs articulate architectural decisions and trade-offs; repos show deliberate structure across multiple languages or stacks; cross-repo ecosystem contributions demonstrating design influence. Peer-attested: their designs are reviewed as the reference; trusted to set boundaries for medium-to-large systems.
Sets architecture for multi-team systems. Anticipates issues 6–12 months out. Can credibly argue for and against a given pattern. Knows when proven solutions don't apply and is comfortable inventing.
Git-visible: owns repos others fork and build upon (high star/fork counts); authored ecosystem contributions into external projects; multi-year sustained maintenance of non-trivial systems across multiple orgs. Peer-attested: sets architecture for multi-team systems; can credibly argue for and against a pattern and is heeded.
Knowing what to test, what not to test, and how to prove the code does what it claims.
Writes tests when asked. Tests mostly mirror the happy-path implementation. Doesn't think about test pyramid.
Unit tests with single assertions on simple paths; no edge cases; no failure modes tested.
Writes unit tests for new code. Aware of test types (unit/integration/e2e) but mixes them up. Tests pass on first try suspiciously often.
Coverage rises on their PRs but bugs still slip through; tests rarely catch regressions.
Writes tests that fail in the right way before fixing them. Picks the right test level for a given concern. Refactors tests as the design evolves.
TDD or test-first visible in commit sequences. Regression tests follow bug fixes. Distinguishes flaky tests from real ones and fixes them.
Designs the test strategy for a service: where contract tests sit, what's stubbed, what runs in CI vs nightly. Pushes back on low-value tests. Drives flakiness down systematically.
Git-visible: high test-file ratio across authored repos; CI/CD present in multiple repos; PR patterns show test-first commits and regression tests on bug fixes. Peer-attested: owns the test strategy for a service; pushes back on low-value tests in review.
Sets the bar for testability across teams. Designs for testability up front. Knows when formal methods, property-based testing, or chaos engineering pay off.
Git-visible: authored testing libraries or frameworks with meaningful adoption (stars/forks); ecosystem contributions to test tooling repos; sustained multi-repo pattern of test infrastructure ownership. Peer-attested: sets the testability bar across teams; consulted on when property-based testing or chaos engineering pays off.
Recognizing when code or systems create risk — and knowing what to do about it.
Doesn't think about security unless an alert fires. Hard-codes credentials in development. Trusts user input.
Secrets in commit history; SQL string concatenation; no input validation.
Knows OWASP Top 10 exists; can name a couple. Uses prepared statements because the team does. Asks before adding a new dependency.
PRs occasionally caught by reviewers for injection or XSS issues; uses auth middleware correctly when scaffolded.
Threat-models their own changes informally. Knows authentication vs authorization. Reasons about least privilege when designing APIs. Reads dependency CVEs when alerted.
PRs include input validation, authz checks, secret management. Flags security concerns in code review.
Designs services with explicit trust boundaries. Reviews others' code for security issues. Triages CVEs and decides what's actually exploitable. Participates in incident response for security events.
Git-visible: CI/CD pipelines with security scanning; authored repos showing systematic auth/authz patterns; cross-repo review activity on security-sensitive PRs. Peer-attested: reviews others' code for security issues; participates in incident response for security events.
Sets security posture for a domain. Designs cryptography or auth systems (and knows when not to). Mentors the org on secure design patterns.
Git-visible: authored security libraries with significant adoption; ecosystem contributions to auth or cryptography repos; multi-year maintained security-critical authored codebases. Peer-attested: sets security posture for a domain; mentors the org on secure design patterns.
Making code fast enough — and knowing when 'enough' has been reached.
Doesn't think about performance until something is visibly slow. Optimizes via guessing. Conflates micro-benchmarks with system performance.
Premature micro-optimizations alongside obvious inefficiencies; no measurement.
Knows Big-O notation but applies it inconsistently. Recognizes common pitfalls (N+1 queries, nested loops on large data) when pointed out.
Uses cache when the senior says to; rarely measures impact.
Profiles before optimizing. Identifies whether the bottleneck is CPU, I/O, network, or human. Knows the system's hot paths. Avoids unnecessary optimization.
Authors PRs with before/after benchmark numbers. Comments in code explain why this loop is hot.
Designs systems with performance budgets up front. Knows the latency tax of every layer (TLS, JSON parsing, DB roundtrip, GC). Drives systematic performance improvements.
Git-visible: authored repos with benchmark tooling or profiling infrastructure; PRs reference measurement data; CI/CD pipelines include performance regression gates. Peer-attested: owns performance budgets; drives systematic performance improvements across the team.
Predicts scaling cliffs before they hit. Designs across the stack (database engine choice, query patterns, caching topology, network topology) coherently.
Git-visible: owns high-adoption performance-critical libraries (significant stars/forks); authored contributions to runtime or infrastructure repos; multi-year maintained authored codebases handling at-scale workloads. Peer-attested: predicts scaling cliffs before they hit; designs coherently across the whole stack.
Writing the words that let other people (including future-you) use, modify, and operate the code.
Writes docs only when prompted. READMEs are out of date. Docstrings are missing or restate the function name.
'TODO: add docs' comments; READMEs say 'see code.'
Adds docstrings on request. Writes setup steps. Doesn't update docs when code changes.
Docs are accurate at the moment of PR, but rot fast.
Writes docs that let a peer use the API without asking questions. Updates docs in the same PR as the code. Knows the difference between reference, tutorial, and explanation.
New module includes a README explaining why it exists, not just what it does. Examples actually run.
Designs the doc set for a service. Anticipates what readers need at each stage (onboarding, integration, troubleshooting). Writes ADRs that explain decisions, not just designs.
Git-visible: high README substance rate across authored repos; PR descriptions consistently explain motivation and trade-offs; authored repos with wikis or detailed contributor guides. Peer-attested: designs the doc set for a service; writes ADRs others rely on.
Sets writing standards for the org. Their docs are the canonical reference. Writes for audiences beyond engineering (PMs, execs, customers).
Git-visible: authored documentation-heavy repos with high adoption (stars/forks); cross-repo ecosystem contributions that include documentation improvements; README substance present across a broad authored footprint. Peer-attested: their docs are the canonical reference; sets writing standards across the org.
Using Git and the surrounding workflow tools (PRs, issues, CI) to collaborate without stepping on toes.
Knows add, commit, push, pull. Force-pushes to shared branches. Commit messages are 'wip' or 'fix.' Resolves merge conflicts by accepting whichever side looks closer.
Linear, ugly history; force-pushes to main; 'fixed merge' commits.
Uses feature branches. Writes more-than-one-word commit messages. Can rebase with help. Opens PRs of moderate size.
PRs sometimes 50+ files; commit history shows multiple 'address review comments' commits.
Writes commit messages that explain why. Keeps PRs small and focused. Rebases cleanly. Uses CI signals (red/green) competently.
Commit messages reference issues; PRs land in <500 lines on average; rare CI breakages on main.
Designs the branching strategy and CI pipeline. Knows when to use trunk-based vs Git Flow. Cherry-picks deliberately. Authors monorepo tooling.
Git-visible: CI/CD present across multiple authored repos; consistent semver release discipline with regular cadence; PRs small and focused with clean commit history. Peer-attested: designs the branching strategy and CI pipeline for the team.
Sets workflow norms across teams. Designs release engineering processes. Defines what a 'good' PR/CI/release looks like for the org.
Git-visible: authored release tooling or CI infrastructure with meaningful adoption (stars/forks); sustained multi-repo release discipline with semver adherence; ecosystem contributions to DevEx or CI tooling repos. Peer-attested: sets workflow norms across teams; defines what a good PR/CI/release looks like for the org.
Knowing what's running in production, how it's behaving, and what to do when it isn't.
Code goes to production via someone else. Doesn't know what dashboards exist. Surprised when their code causes an alert.
No dashboard ever opened by them; no on-call shifts.
Watches their deploys land. Knows there's a logging system. On-call rotation participant but escalates immediately.
Logs into Datadog/Grafana occasionally; resolves their own paging incidents with help.
Adds metrics, logs, and traces with new code. Owns dashboards for what they ship. Handles routine on-call incidents independently.
Authors alerting rules; runbooks exist for their services; reduces alert fatigue on their pager.
Designs observability for services up front. Drives incident response calmly. Writes useful postmortems. Reduces toil systematically.
Git-visible: CI/CD pipelines across authored repos include monitoring/alerting config; authored repos show infrastructure-as-code patterns; sustained multi-year maintenance of production systems. Peer-attested: drives incident response calmly; writes useful postmortems; reduces toil systematically.
Sets observability standards across the org. Designs the on-call experience. Predicts operational failure modes during architecture review.
Git-visible: authored operational tooling with broad adoption (high stars/forks); ecosystem contributions to observability or infrastructure repos; multi-year maintained authored systems demonstrating operational maturity. Peer-attested: sets observability standards across the org; designs the on-call experience.
Using AI coding tools to increase output quality and speed — without outsourcing judgment. The key behavioral marker at every level is the delegation boundary.
Uses AI suggestions by accepting them without reading. Pastes error messages into the chat and copies the first response. Can't reliably tell when output is wrong. Treats the AI as an oracle.
Introduced bugs that were obviously AI-generated; accepted suggestions that broke tests silently; can't explain their own recent code when asked.
Uses completions and generation for boilerplate and syntax lookup. Reads what it returns before accepting. Catches obvious errors but misses subtle ones. Knows when to ask again but not always when to stop asking.
Reduced time on scaffolding tasks; still produces code that needs architectural cleanup; over-applies AI to tasks it handles poorly.
Has a working mental model of where AI is strong (transformation, boilerplate, well-trodden patterns) vs. weak (subtle bugs, system-level tradeoffs, novel problems). Uses AI to accelerate work within those bounds. Reviews AI output with the same critical eye as a junior's PR.
Measurably faster on routine work; AI output in their PRs is clean by merge; can articulate why they rejected an AI suggestion; tests co-developed or written first.
Uses AI as a thinking partner, not just a code generator — to pressure-test designs, enumerate failure modes, draft docs and specs, and explore approaches before committing. Calibrates tool choice. Mentors junior engineers on failure modes.
Git-visible: authored repos that include AI tooling, prompt engineering, or eval harnesses; consistent commit patterns showing deliberate AI-assisted workflow integration; cross-repo contributions in LLM/AI tooling space. Peer-attested: uses AI as a thinking partner to pressure-test designs; mentors juniors on AI failure modes.
Designs workflows and tooling that extend AI-assisted development to the team level (custom prompts, eval harnesses, context strategies, agent scaffolding). Identifies the limits of current AI tooling precisely. Can teach the failure modes from first principles.
Git-visible: owns AI tooling repos with meaningful adoption (stars/forks); authored ecosystem contributions to LLM frameworks or agent scaffolding projects; broad authored footprint across AI/ML infrastructure repos. Peer-attested: designs team-level AI workflows and tooling; teaches AI failure modes from first principles.
Fluency in specific languages and tools. Evidence comes from what you actually ship — language distribution, idiomatic structure, and ecosystem contribution — not what’s on your resume.
General-purpose dynamic language; dominant in scripting, data, ML, and increasingly backend.
Writes scripts; uses pip install to find solutions; doesn't grasp scope or mutability rules.
Tutorial-style commits; copy-paste solutions; no idiomatic structure.
Builds Flask/FastAPI apps or Pandas scripts; knows comprehensions and with blocks; uses virtualenv inconsistently.
Working features but non-idiomatic; uses high-level libs without understanding internals.
Writes idiomatic Python; uses type hints; knows GIL implications; comfortable with asyncio and packaging.
Consistent idiomatic style across repos; uses language-appropriate tooling.
Designs library APIs; profiles with cProfile/py-spy; reasons about CPython internals; mentors on packaging and tooling (uv/poetry/ruff).
Git-visible: owns X-language repos with meaningful adoption (stars/forks); merged PRs into external X ecosystem repos; cross-repo review activity on X codebases. Peer-attested: mentors others on X; their opinions on which X patterns are wrong carry weight.
Contributes to CPython or major libs (Pandas/NumPy/PyTorch); speaks at PyCon; influences ecosystem direction.
Git-visible: authored X packages with high star/fork counts; merged upstream contributions into core X ecosystem repos; broad authored footprint across multiple X-language projects with sustained maintenance. Peer-attested: maintains a popular library, makes upstream contributions, or is recognized in the X community.
The browser and Node ecosystem; TypeScript adds gradual static typing on top.
Writes browser scripts; confused by this, async, hoisting.
Tutorial-style commits; copy-paste solutions; no idiomatic structure.
Builds React components or Node APIs; uses async/await; reaches for Lodash; TS types are any.
Working features but non-idiomatic; uses high-level libs without understanding internals.
Idiomatic modern JS/TS; understands the event loop, modules, strict TS; ships type-safe code.
Consistent idiomatic style across repos; uses language-appropriate tooling.
Designs library APIs with rigorous types (generics, conditional types); navigates bundler/runtime ecosystem (Vite, esbuild, Bun, Deno) with informed opinions.
Git-visible: owns X-language repos with meaningful adoption (stars/forks); merged PRs into external X ecosystem repos; cross-repo review activity on X codebases. Peer-attested: mentors others on X; their opinions on which X patterns are wrong carry weight.
Maintains a TC39 proposal, popular library, or major TS infrastructure; recognized voice in the JS/TS community.
Git-visible: authored X packages with high star/fork counts; merged upstream contributions into core X ecosystem repos; broad authored footprint across multiple X-language projects with sustained maintenance. Peer-attested: maintains a popular library, makes upstream contributions, or is recognized in the X community.
Memory-safe systems language with a strong type system and ownership model.
Fights the borrow checker; copies Cargo configs.
Tutorial-style commits; copy-paste solutions; no idiomatic structure.
Ships small CLIs; understands ownership at the surface level; uses clone() too much.
Working features but non-idiomatic; uses high-level libs without understanding internals.
Writes idiomatic Rust; comfortable with traits, lifetimes, error handling (thiserror/anyhow); knows when to reach for unsafe.
Consistent idiomatic style across repos; uses language-appropriate tooling.
Designs library APIs that leverage the type system; uses async Rust (tokio/async-std) competently; mentors on lifetime puzzles.
Git-visible: owns X-language repos with meaningful adoption (stars/forks); merged PRs into external X ecosystem repos; cross-repo review activity on X codebases. Peer-attested: mentors others on X; their opinions on which X patterns are wrong carry weight.
Maintains a crate on lib.rs with significant adoption; contributes to compiler/std; speaks at RustConf.
Git-visible: authored X packages with high star/fork counts; merged upstream contributions into core X ecosystem repos; broad authored footprint across multiple X-language projects with sustained maintenance. Peer-attested: maintains a popular library, makes upstream contributions, or is recognized in the X community.
Statically typed, garbage-collected language; designed for backend services and tooling.
Writes Go like Java; over-uses interfaces; ignores error returns.
Tutorial-style commits; copy-paste solutions; no idiomatic structure.
Ships HTTP services; uses goroutines and channels by example; doesn't always cancel contexts.
Working features but non-idiomatic; uses high-level libs without understanding internals.
Idiomatic Go; understands context propagation, sync primitives, error wrapping; comfortable with go test/go bench.
Consistent idiomatic style across repos; uses language-appropriate tooling.
Designs library APIs that honor Go idioms; reasons about GC and escape analysis; mentors on concurrency.
Git-visible: owns X-language repos with meaningful adoption (stars/forks); merged PRs into external X ecosystem repos; cross-repo review activity on X codebases. Peer-attested: mentors others on X; their opinions on which X patterns are wrong carry weight.
Contributes to stdlib or major Go projects; speaks at GopherCon.
Git-visible: authored X packages with high star/fork counts; merged upstream contributions into core X ecosystem repos; broad authored footprint across multiple X-language projects with sustained maintenance. Peer-attested: maintains a popular library, makes upstream contributions, or is recognized in the X community.
The query language of relational databases; cuts across multiple engines.
Writes SELECTs from one table; doesn't grasp joins.
Tutorial-style commits; copy-paste solutions; no idiomatic structure.
Joins multiple tables; uses GROUP BY; doesn't think about indexes.
Working features but non-idiomatic; uses high-level libs without understanding internals.
Writes correct, indexed queries; understands query plans; comfortable with window functions and CTEs.
Consistent idiomatic style across repos; uses language-appropriate tooling.
Designs schemas; tunes complex queries from EXPLAIN output; understands isolation levels and locking.
Git-visible: owns X-language repos with meaningful adoption (stars/forks); merged PRs into external X ecosystem repos; cross-repo review activity on X codebases. Peer-attested: mentors others on X; their opinions on which X patterns are wrong carry weight.
Designs data architectures across OLTP and OLAP; deep knowledge of at least one engine internals.
Git-visible: authored X packages with high star/fork counts; merged upstream contributions into core X ecosystem repos; broad authored footprint across multiple X-language projects with sustained maintenance. Peer-attested: maintains a popular library, makes upstream contributions, or is recognized in the X community.
JVM language; dominant in enterprise backends and the Android platform.
Copies tutorial Spring scaffolds; doesn't grasp JVM/classpath semantics.
Tutorial-style commits; copy-paste solutions; no idiomatic structure.
Builds Spring Boot services; uses Maven/Gradle by convention; unfamiliar with the streams API.
Working features but non-idiomatic; uses high-level libs without understanding internals.
Idiomatic modern Java (records, sealed types, streams); comfortable with JVM tuning basics; uses dependency injection appropriately.
Consistent idiomatic style across repos; uses language-appropriate tooling.
Designs reactive or high-throughput services; reasons about GC and JIT behavior; mentors on Spring patterns and module systems.
Git-visible: owns X-language repos with meaningful adoption (stars/forks); merged PRs into external X ecosystem repos; cross-repo review activity on X codebases. Peer-attested: mentors others on X; their opinions on which X patterns are wrong carry weight.
Contributes to the JDK or major open-source frameworks; speaks at JavaOne/Devoxx.
Git-visible: authored X packages with high star/fork counts; merged upstream contributions into core X ecosystem repos; broad authored footprint across multiple X-language projects with sustained maintenance. Peer-attested: maintains a popular library, makes upstream contributions, or is recognized in the X community.
Communication, mentorship, leadership, product thinking. Only peer attestation can assess these — code alone can’t. Shown here so raters can see the behaviors they’re affirming.
Conveying technical ideas to other humans — in PRs, docs, meetings, talks, and writing.
Status updates are "still working on it." Writes one-line PRs and Slack questions without context. Defers to others in meetings.
PR descriptions empty or restate the title; questions need 3 follow-ups to interpret.
Writes coherent status updates. Asks questions with attached context. Presents to the team when prompted.
PR descriptions include "what" but not "why." Questions in Slack include logs and a hypothesis.
Writes design docs others can read. Explains technical decisions to PMs/designers without being asked. Runs effective standups and demos.
Authors design docs others read; PR descriptions explain motivation, trade-offs, rollback plan.
Communicates fluently across audiences (engineering, product, exec). Anticipates what each audience needs to hear. Tailors level of abstraction. Mediates disagreements.
Quoted in cross-team docs; runs cross-functional meetings; turns complex tech topics into one-pagers for execs.
Communicates at executive level and externally. Sets writing/talking norms across the org. Writes externally (blog/talks/book) that shape practice.
Conference talks; blog posts cited by peers outside the company; messaging adopted org-wide.
Reviewing others' code in a way that improves both the code and the author.
Stamps PRs with "LGTM" without reading deeply. Comments only on style. Does not review at all unless assigned.
Review turnaround low because review is shallow; comment ratio ~0.
Reads code carefully but mostly catches style and naming issues. Sometimes catches logic bugs. Defers to senior reviewers on architecture.
Comments are real but mostly surface-level; rarely blocks.
Catches logic bugs, missed edge cases, test gaps. Asks "what about X" questions. Suggests refactors with reasoning. Balances thoroughness with shipping pace.
Authors see "nice catch" responses; comments include alternative approaches.
Reviews include design-level feedback. Identifies cross-cutting concerns. Mentors authors through review — explains why. Sets review tone (kind, precise, decisive).
Authored review guidelines; their reviews are sought out; junior engineers cite them as teachers.
Sets review culture. Reviews architectural designs and contracts, not just code. Drives org-wide review norms (size limits, response SLAs).
Quoted in eng-culture docs; their review comments are referenced as canonical.
Investing in other engineers' growth — through teaching, pairing, writing, and feedback.
Receives mentorship; rarely gives it back. Pairs to learn, not teach.
Mentees: 0; in 1:1s mostly asks questions.
Helps peers with small things — "have you tried X?" Onboards new hires when assigned.
Onboarding docs sometimes touched; intern questions in Slack answered.
Actively mentors 1–2 juniors. Pairs to teach. Gives feedback that lands. Spreads useful knowledge in the team.
Tagged in team retros for mentorship; team lunch-and-learn host; updated onboarding docs.
Mentor of record for multiple engineers. Sponsors growth (puts mentees on visible projects). Identified by manager as a force multiplier.
Mentees referenced them in 360 reviews; tracked by management as a key developer.
Mentors senior engineers — including peers and people more senior than them. Builds programs (interview training, internal classes). Writes/speaks externally on craft.
Quoted as the reason others stayed/grew; runs cross-org mentorship efforts; recognized publicly.
Driving technical work end-to-end — scoping, sequencing, deciding, delivering — and being accountable for the outcome.
Completes assigned tasks; doesn't shape what gets done.
Tickets are picked up, not authored.
Owns small features end-to-end with guidance. Asks for help when blocked.
Authored a few tickets; ships small features; needs nudging on prioritization.
Tech-leads small projects. Breaks down work into milestones. Coordinates 2–3 engineers. Identifies risks early.
Authored project plan or design doc; on-time delivery without heroics.
Tech lead for cross-functional projects. Identifies the right problem to work on. Sequences work to ship value incrementally. Manages risk and dependencies actively.
Quarterly OKR owner; named lead in retros; balances scope vs. timeline credibly.
Drives multi-team initiatives. Defines what the team should be working on, not just how. Creates leverage — invests in tools/practices that raise everyone's output.
Author of multi-quarter strategy docs; "force multiplier" cited by engineering leadership; drives org-level technical bets.
Working effectively with PMs, designers, data scientists, support, sales, and other non-engineering partners.
Avoids cross-functional meetings. Communicates only through engineering.
Cross-functional partners don't know their name.
Attends spec reviews; asks clarifying questions. Doesn't push back on requirements.
Receives specs and implements; product surprises in QA.
Partners with PM/design throughout a project. Surfaces tradeoffs early. Translates engineering constraints into product impact.
Frequently in spec reviews; named in PM's project docs.
Shapes product decisions, not just implementation. Anticipates customer/business impact. Mediates between engineering and other functions.
Co-authors product specs; cited by PM as a partner; influences roadmap.
Trusted partner for senior product/exec leadership. Shapes business strategy. Bridges engineering with the rest of the company.
Quoted in exec-level decisions; named in cross-functional 360 reviews; sits on cross-functional steering groups.
Understanding why the company exists, what the customer needs, and how engineering choices map to business outcomes.
Doesn't know what the company sells beyond the team-level view. Doesn't think about users.
Builds features without questioning them.
Knows the product area; asks "what does the user see?" questions.
Asks PM clarifying questions about UX.
Understands the business unit's goals. Makes technical decisions with user impact in mind. Suggests product improvements.
Proposes UX or product improvements in tickets; reads customer support feedback.
Deep knowledge of customer/business context. Identifies high-impact opportunities. Distinguishes "important" from "interesting" work. Pushes back on low-value features.
Drives product changes from an engineering origin; reads churn data; talks to customers.
Fluent in company strategy, financials, and competitive landscape. Identifies bets that move company-level outcomes.
Influences company strategy; quoted in board-level decks; respected by CEO/founders.