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 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, 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: