Personal Development Plan (PDP) Checklist

A structured PDP workflow for software engineers and engineering managers to assess current skills, set growth goals tied to a career ladder, plan concrete learning, and track progress over a quarterly review cycle.

1

Self-Assessment

  1. Score yourself against the career ladder
    • Walk through each rubric line in the engineering career ladder (system design, code quality, mentorship, project leadership, cross-team impact) and rate yourself Below / Meets / Exceeds. Cite specific PRs, RFCs, or incidents as evidence — vague self-ratings without artifacts get pushed back at calibration.

    Collects list
  2. Inventory technical and craft strengths
    • List the languages, frameworks, and systems where you ship confidently without supervision (e.g., Go services on EKS, Postgres schema design, React + TypeScript). Distinguish 'used once in a tutorial' from 'shipped to production and on-call for'.

  3. Identify skill gaps blocking your next level
    • Compare your ladder self-rating to the next level's expectations. Common gap patterns: senior candidates lack cross-team RFC authorship; staff candidates lack org-level technical strategy; managers lack performance-management reps. Name the 2-3 gaps that matter most, not all of them.

  4. Request 360 feedback from peers and manager
    • Send 4-6 short feedback requests: your manager, a peer who reviews your code, a downstream consumer of your service, and (if applicable) someone you've mentored. Ask for one specific strength and one specific area to grow, not open-ended praise.

    Collects paragraph
2

Goal Setting

  1. Choose a target ladder level for this cycle
    • Decide whether this PDP cycle is a level-up cycle (promotion target) or a depth cycle (consolidate at current level). Promotion cycles typically need 6-12 months of evidence at the next level before calibration — be honest about timeline.

    Collects list
  2. Draft three SMART goals tied to the gaps
    • Each goal should name an artifact, not an activity. 'Author and ship the auth-service migration RFC by Q3' beats 'get better at system design.' Three goals max — five-goal PDPs always collapse into two-goal PDPs by week six.

    Collects paragraph
  3. Align goals with team roadmap and OKRs
    • Cross-check each goal against the team's quarterly OKRs and the next two epics on the roadmap. PDPs that float free of team commitments don't get calibration credit — the goal needs to land on work the team is already doing.

  4. Assemble promotion evidence plan
    • For each ladder line at the target level, identify the project or artifact that will demonstrate it: a cross-team RFC, an incident command rep, a mentee's promotion, a quarter of on-call leadership. Calibration committees read evidence packets; build the packet on purpose.

3

Skill Development Plan

  1. Pick technical learning resources
    • Choose 1-2 concrete resources per goal — a Pluralsight or Frontend Masters course, a book (DDIA, Staff Engineer's Path), a certification track (CKA, AWS Solutions Architect). Don't pick five; the unfinished-course graveyard is the most common PDP failure mode.

    Collects paragraph
  2. Volunteer for a stretch project on the roadmap
    • Identify one upcoming epic where you'd be a stretch — owning the RFC, leading a cross-team integration, driving a perf or reliability initiative. Get manager buy-in to take it before someone else picks it up at planning.

  3. Schedule deliberate practice in non-production
    • Block calendar time for the things you can't practice in production: chaos drills in staging, system-design whiteboarding, presenting an RFC to a peer group. Skills that only appear under pressure don't develop on the job alone.

  4. Pair on production incidents during on-call
    • Shadow the IC role on at least one SEV2 during the cycle, or scribe a SEV1. Incident command is one of the few skills that genuinely cannot be learned from a course — only from reps with someone watching.

4

Promotion Evidence Building

  1. Author the cross-team technical RFC
    • Write and circulate one RFC that requires sign-off from at least two teams outside your own. Senior+ ladder lines call out 'influences technical direction beyond own team' — the RFC is how that line gets evidence.

  2. Mentor a junior engineer on a shipped project
    • Pair regularly with one junior engineer through a project to GA. 'Mentored John on intern project' doesn't land at calibration; 'Mentored Priya through her first on-call rotation, leading to her SEV2 IC rep' does.

  3. Present at an internal eng all-hands or guild
    • Pick a topic from your stretch project — an architecture decision, an incident retrospective, a perf win — and present it to engineering. Visibility is part of what calibration committees weigh, fairly or not.

5

Professional Network and Community

  1. Attend one industry conference or local meetup
    • Pick something concrete — KubeCon, SREcon, RailsConf, Strange Loop, a local Rust or Go meetup. Submit a CFP if the timing fits; speaking accelerates promotion-evidence faster than attending.

  2. Contribute to an open-source project or internal library
    • One non-trivial PR to a dependency you actually use, or to an internal shared library outside your team's ownership. 'Contributed to OSS' as a one-liner in a packet falls flat; a merged PR with a link does not.

  3. Establish a recurring mentor or sponsor 1:1
    • Identify a senior engineer or EM (inside or outside your org) and set a monthly 30-minute 1:1. Mentors give advice; sponsors advocate in rooms you're not in. For promotion cycles, you need at least one of each.

6

Progress Tracking and Calibration

  1. Hold the 30-day check-in with your manager
    • Walk through goal status, blockers, and any goal that needs to be killed or rewritten. PDPs are living documents; goals that no longer match the roadmap should be rewritten now, not defended at quarter-end.

  2. Hold the 60-day mid-cycle review
    • Bring evidence artifacts to the review: shipped PRs, RFC links, mentee progress, incident-command reps. If you can't link to artifacts at day 60, the day-90 packet won't materialize either.

  3. Compile the end-of-cycle evidence packet
    • One document, ladder-line by ladder-line, with linked evidence under each. Manager reviews before submission to calibration. Promotion packets without organized evidence get deferred regardless of the underlying work.

    Collects list Collects file Collects paragraph