career-ladder-author

Overview

Without a written ladder, promotions ride on tenure and advocacy, and the answer to "what do I need to do to get promoted?" changes per manager. A career ladder fixes that by defining, per level, the expected scope and the observable evidence that someone already operates at it.

The reference shape comes from public engineering frameworks. The Dropbox Engineering Career Framework (opens in new window) defines an IC track (IC1 - IC7) and a management track (M3 - M7), explicitly includes Quality Engineer and SDET among its IC roles, evaluates each level on the pillars Results, Direction, Talent, Culture, Craft, and states that "Level Expectations define the scope, collaborative reach, and levers for impact at every level." Dozens of other public frameworks (GitLab, Spotify, Square, Etsy) are indexed at progression.fyi (opens in new window), which collects 75 public and open-source career frameworks; study 2 - 3 before drafting, then adapt to QA-specific craft.

For the management track and the dual-ladder split, the canonical practitioner reference is Camille Fournier, The Manager's Path (O'Reilly, 2017), whose "Managing People" chapter treats career cultivation ("Cultivating Careers") as a distinct management duty rather than a side effect of reviews. Full citation in References.

When to use

• A QA org above ~5 testers has no written leveling criteria, or has criteria that exist only in the head of one manager.
• Promotion season exposes inconsistency: two testers with similar work are leveled differently across teams.
• Senior ICs are leaving or drifting toward management because the IC track visibly tops out.
• Compensation banding requires defensible level definitions.

Do not use this skill to:

• Decide one specific person's promotion - the ladder is the standard; the case is built from evidence via performance-feedback-author.
• Map what the team can do today - that is skill-matrix-author.
• Define a single role for hiring - that is qa-jd-author in qa-hiring.

Step 1 - Capture the inputs

Step 2 - Fix the track structure

Decide three structural facts before writing any criteria:

1. Two parallel tracks. An IC track and a management track, with the split point and the equivalences stated (Dropbox: IC track to IC7, management entering at M3, both framed in the same level-expectation language - dbx-career-framework (opens in new window)). The dual ladder exists so that management is a role change, not the only raise; The Manager's Path makes the same point from the other side: management is a distinct skill set to be learned, not a seniority reward.
2. Level count. Small orgs: 4 - 5 IC levels (junior, mid, senior, staff, principal). Do not copy a 7-level framework into a 12-person org; empty levels invite title inflation.
3. Axes held constant across levels. Pick 4 - 5 axes and define every level on the same axes, so adjacent levels differ by scope rather than by category. The Dropbox pillar set (Results, Direction, Talent, Culture, Craft) adapts well to QA with Craft expanded into QA-specific terms (test strategy, automation architecture, quality advocacy).

Step 3 - Write per-level criteria with observable promotion evidence

Each level gets: a scope sentence, per-axis criteria on the fixed axes, and an evidence list stating what an existing-at-this-level person has already done. Promotion is recognition of demonstrated scope, not potential. Every level also carries an "explicitly not evidence" block - time in level, test-case volume, certifications alone, sole-keeper-of-knowledge - and that block is what keeps the ladder honest at promotion time. Minimal shape:

## QA-IC3 - Senior QA Engineer
**Scope:** one sentence naming the scope owned end to end without review.
| Axis | Expectation |   (one row per fixed axis, each phrased as an observable)
**Observable promotion evidence (from work already done at the level below):** linkable artifacts, not adjectives.
**Explicitly not evidence:** time in level; test-case volume; certifications alone.

See references/level-criteria-example.md for the full QA-IC3 level worked across all five axes with its evidence and not-evidence blocks.

Step 4 - Write the management track as a role change

Management levels (QA-M1 lead, QA-M2 manager, QA-M3 head/director or per the org's grid) get the same axis treatment, with Craft partially replaced by people and process responsibilities: hiring (hand off to the qa-hiring chain), 1:1s and growth (tester-one-on-one-planner), feedback and reviews (performance-feedback-author), capability planning (skill-matrix-author). The Manager's Path sequences these duties chapter by chapter (mentoring, then tech lead, then managing people, then managing a team) and is the calibration reference for what each management level actually does day to day.

State the transfer rule explicitly: moving IC->M or M->IC at equivalent level is a lateral move, not a promotion or demotion. Frameworks that omit this quietly re-create the management-only ceiling.

Step 5 - Document the anti-patterns the ladder forbids

Ship the ladder with its failure modes named, so calibration meetings can cite them:

Anti-patterns (of authoring the ladder itself)

• Authoring without engineering-ladder alignment. If QA-IC3 and ENG-IC3 are not calibration-equivalent, transfers and pay bands break; align the grids before publishing.
• Publishing without a calibration process. A ladder without a cross-team calibration meeting reverts to per-manager interpretation within two cycles.
• Treating the ladder as immutable. Revisit yearly; role families change (e.g., an SDET track may need to split out as automation scope grows).

Limitations

• Compensation mapping is out of scope. The ladder defines levels; attaching salary bands is a compensation exercise with market data this skill does not carry.
• Public frameworks are inputs, not authority. Dropbox's pillars fit Dropbox; the fetched frameworks ground the shape, while the criteria content must come from the org's own QA work.
• Small-org floor. Below ~5 testers a written ladder is mostly ceremony; a lightweight level note per person plus the skill matrix is usually enough.
• Book guidance is uncited-by-page. The Manager's Path is cited by ISBN as a management framework; teams wanting verbatim guidance should read the "Managing People" and "Managing a Team" chapters directly.

Hand-off targets

• Measure today's capability against the new levels → skill-matrix-author.
• Run the growth conversations the ladder enables → tester-one-on-one-planner.
• Build a promotion case from evidence → performance-feedback-author.
• Hire into a level → qa-jd-author and the qa-hiring structured-interview chain.

References

• Dropbox Engineering Career Framework - IC1 - IC7 and M3 - M7 tracks, Results/Direction/Talent/Culture/Craft pillars, Quality Engineer and SDET role coverage: https://dropbox.github.io/dbx-career-framework/ (fetched 2026-06-10).
• progression.fyi - index of 75 public and open-source career frameworks (GitLab, Spotify, Square, Etsy, and others) for Step 1 reference selection: https://progression.fyi/ (fetched 2026-06-10).
• Camille Fournier, The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, O'Reilly 2017, ISBN 978-1491973899 - management-track duties, dual-ladder rationale, "Cultivating Careers".
• skill-matrix-author, tester-one-on-one-planner, performance-feedback-author - sibling skills this ladder composes with.