# Individual Development Plan: [Name], [Period]

> An individual development plan (IDP) agreed between an employee and
> their manager: career direction, current strengths and gaps against
> the role's competencies, two to four development goals, the actions
> and support for each, a budget, and check-in dates. Based on common
> talent-development practice. Replace every `[bracketed]` value and
> every row marked *Example*.

<!--
Guidance: How to use this template
- The employee drafts sections 1 to 4; the manager adds support,
  budget and opportunities in sections 5 and 6; both agree the plan in
  one conversation and sign it off.
- Keep the plan separate from the performance rating. An IDP is about
  growth; mixing it with a rating discussion makes people hide gaps.
  A plan to fix performance problems is a different document (see
  `hr/performance-improvement-plan`).
- Limit it to two to four goals for six to twelve months. Most of the
  learning happens through work assignments, so every goal needs at
  least one on-the-job action, not only courses.
- Worked example: the fictional Priya Raman, Senior Engineer (L3) on
  the payments platform team at Larkspur Analytics, the same person as
  in `career/brag-document`. All names, figures and IDs are invented.
- Related templates: Engineering Career Ladder
  (`career/engineering-career-ladder`), Performance Self-Assessment
  (`career/performance-review`), Brag Document
  (`career/brag-document`), Promotion Packet
  (`career/promotion-packet`), One-on-One (`meetings/one-on-one`).
-->

## Document control

<!-- Guidance: Record who agreed the plan and when it will be reviewed. Pitfall: a plan with no review date, which nobody opens again. -->

| Field | Value |
|---|---|
| Document ID | [IDP-YYYY-NNN] *Example:* IDP-2027-014 |
| Employee | [Name, role, level] *Example:* Priya Raman, Senior Engineer, L3 |
| Manager | [Name, role] *Example:* Daniel Osei, Engineering Manager |
| Period | YYYY-MM-DD to YYYY-MM-DD *Example:* 2027-01-01 to 2027-12-31 |
| Check-in cadence | [Monthly in one-on-ones, formal review each quarter] |
| Status | [Draft / Agreed / In progress / Closed] |
| Classification | Confidential, employee and manager only |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Date |
|---|---|---|
| Employee | [Name] | YYYY-MM-DD |
| Manager | [Name] | YYYY-MM-DD |

### Revision history

| Version | Date | Change |
|---|---|---|
| 0.1 | YYYY-MM-DD | Employee draft |
| 1.0 | YYYY-MM-DD | Agreed in development conversation |
| 1.1 | YYYY-MM-DD | *Example:* Q2 review: G2 action changed after team reorganisation |

## 1. Career direction

<!-- Guidance: Two or three sentences in the employee's words. Where do you want to be in two to three years, and why? It is fine to be unsure; say which options you want to explore. Pitfall: writing what you think the manager wants to hear. -->

- Two to three year aspiration: [Role, scope, kind of work]
- What motivates me in my work: [Problems, people, impact]
- Options I want to explore: [Technical lead, management, another domain]

*Example:* My L4 (Staff Engineer) case is in the 2027-H1 cycle; in two
to three years I want to set the technical direction for payments. I am
unsure about people management and want to try a small lead role before
deciding.

## 2. Strengths and development areas

<!-- Guidance: Assess against the competencies of the current and the next level (for engineers, `career/engineering-career-ladder`). Use evidence: feedback, review results, examples. Rate on a simple scale and say where the evidence comes from. -->

| Competency | Current level | Target level | Evidence | Strength or gap |
|---|---|---|---|---|
| [Competency] | [1 to 5] | [1 to 5] | [Feedback, example, review] | [Strength / Gap] |
| *Example:* Technical design | 4 | 4 | Designed and led the payouts idempotency layer, 2026 (WIN-001 in the brag document) | Strength |
| *Example:* Cross-team influence | 3 | 4 | 2026 self-assessment: event schema adopted by three teams, but reviews ran long in H1 | Gap |
| *Example:* Mentoring | 3 | 4 | Mentored two L2 engineers in 2026, positive feedback | Gap |
| *Example:* Written communication | 3 | 4 | Design docs clear but long, per peer feedback | Gap |

Scale: 1 learning, 2 developing, 3 capable at current level, 4 strong
or at next level, 5 role model.

## 3. Development goals

<!-- Guidance: Two to four goals, each tied to a gap or a strength you want to grow, written so that someone else could tell whether it was met. Give each an ID used in sections 4 and 7. -->

| ID | Goal | Linked competency | Success measure | Target date |
|---|---|---|---|---|
| [G1] | [Goal] | [Competency] | [Observable result] | YYYY-MM-DD |
| G1 *(Example)* | Lead the ledger events v2 design to agreement across teams | Cross-team influence | RFC accepted by payments and finance teams, decision recorded as an ADR | 2027-06-30 |
| G2 *(Example)* | Mentor two engineers through their first on-call rotation | Mentoring | Both complete rotation; mentees rate support 4 of 5 or higher | 2027-09-30 |
| G3 *(Example)* | Write shorter, decision-first design documents | Written communication | Three design docs under 1,500 words with a one-page summary, peer review positive | 2027-12-31 |

## 4. Development actions

<!-- Guidance: For each goal, mix learning on the job (stretch assignments, projects), learning from others (mentoring, feedback, shadowing) and formal learning (courses, reading). A split of roughly 70% experience, 20% people and 10% courses is a commonly cited heuristic, not a rule. -->

| ID | Goal | Action | Type | Owner | Due | Status |
|---|---|---|---|---|---|---|
| [A1] | [G1] | [Action] | [On the job / From others / Formal] | [Name] | YYYY-MM-DD | [Not started / In progress / Done] |
| A1 *(Example)* | G1 | Write and drive the ledger events v2 RFC | On the job | Priya | 2027-05-15 | Not started |
| A2 *(Example)* | G1 | Shadow the principal engineer in two architecture reviews | From others | Priya, Daniel to arrange | 2027-03-31 | Not started |
| A3 *(Example)* | G2 | Pair with each mentee during their first on-call week | On the job | Priya | 2027-09-30 | Not started |
| A4 *(Example)* | G2 | Complete an internal mentoring workshop | Formal | Priya | 2027-04-30 | Not started |
| A5 *(Example)* | G3 | Attend a technical writing course | Formal | Priya | 2027-03-31 | Not started |
| A6 *(Example)* | G3 | Ask two peers to review each design doc for length and clarity | From others | Priya | 2027-12-31 | Not started |

## 5. Support and resources

<!-- Guidance: The manager states what they will do. Specific support (introductions, assignments, time) matters more than budget. Pitfall: an IDP in which only the employee has actions. -->

| Support | Provided by | Detail |
|---|---|---|
| [Stretch assignment] | [Manager] | [What and when] |
| [Mentor or sponsor] | [Name] | [Cadence] |
| [Time] | [Manager] | [Hours per month protected for learning] |
| *Example:* Technical lead role for ledger events v2 | Daniel Osei | Assigned in January planning |
| *Example:* Mentor | Principal engineer, risk platform | Monthly 45-minute session |
| *Example:* Learning time | Daniel Osei | Four hours per month protected |

Budget:

| Item | Cost | Approved |
|---|---|---|
| [Course, conference, book] | [amount] | [Yes / No] |
| *Example:* Technical writing course (online) | EUR 450 | Yes |
| *Example:* One engineering conference ticket | EUR 600 | Yes |
| *Example:* Books and materials | EUR 300 | Yes |
| *Example:* **Total of annual budget EUR 1,500** | **EUR 1,350** | EUR 150 unallocated |

## 6. Obstacles and risks

<!-- Guidance: Name what could stop the plan, and agree in advance how to handle it. -->

| Obstacle | Likelihood | Plan |
|---|---|---|
| [Delivery pressure crowds out learning] | [High / Medium / Low] | [Response] |
| *Example:* Q2 release crunch | High | Move A2 and A5 to Q1; protect learning time again from July |
| *Example:* No suitable mentees join the team | Medium | Mentor across teams through the on-call guild |

## 7. Check-ins and progress

<!-- Guidance: Use part of a monthly one-on-one for a short update, and a longer review every quarter. Record evidence of progress, and change the plan when work changes; an IDP that cannot change gets ignored. -->

| Date | Goals reviewed | Progress and evidence | Changes agreed | Next check-in |
|---|---|---|---|---|
| YYYY-MM-DD | [G1, G2] | [Evidence] | [Change] | YYYY-MM-DD |
| 2027-03-31 *(Example)* | G1, G3 | A2 done; writing course done; first short design doc at 1,200 words | None | 2027-06-30 |

## 8. Year-end summary

<!-- Guidance: Close the plan with what was achieved, what was learned and what carries into the next plan. Copy the evidence into your brag document. -->

| Goal | Outcome | Met? | Carry forward? |
|---|---|---|---|
| [G1] | [Result] | [Yes / Partly / No] | [Yes / No] |

- Employee reflection: [What I learned, what I would do differently]
- Manager reflection: [Observed growth, next opportunities]
- Input to the next plan: [Goals, direction]

## 9. Glossary

- **IDP:** Individual development plan; a growth plan owned by the
  employee and supported by the manager.
- **Stretch assignment:** Work slightly beyond the person's current
  level, with support, chosen for learning.
- **Sponsor:** A senior person who uses their influence to create
  opportunities for someone, unlike a mentor who mainly gives advice.

## Standard and licence note

Based on common talent-development practice for individual development
plans; the 70-20-10 split is cited only as a widely used heuristic.
Original text written for this collection; people, organisations and
figures are fictional. Template licence: MIT.