Personal Development Plan (PDP) Checklist

Self-Assessment

    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.

    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.

Goal Setting

    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.

    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.

Skill Development Plan

    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.

    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.

Promotion Evidence Building

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

Professional Network and Community

    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.

    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.

Progress Tracking and Calibration

    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.

    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.

Use this template in Manifestly

Start a Free 14 Day Trial
Use Slack? Start your trial with one click

Related Software Development Checklists

Ready to take control of your recurring tasks?

Start Free 14-Day Trial


Use Slack? Sign up with one click

With Slack