Personal Development Plan (PDP) Checklist

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.

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'.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.