An individual development plan (IDP) is a short, written agreement about how one person will grow over the next few months: which skills they will work on, what they will actually do, and by when. It sounds like paperwork, and in many companies it is — a form filled in once a year and never opened again. It does not have to be.
This guide shows how to write an IDP that gets done: where the goals come from, what makes an action concrete, a template you can copy, and examples for support, sales, engineering and management roles.
What an individual development plan is, and what it is not
A useful IDP has three things:
- A direction. Usually the next level on the person's career ladder, sometimes a move to a different track or role.
- One or two focus skills. The gaps that stand between the person and that direction.
- A few concrete actions with due dates — the part that actually changes anything.
It is not a performance improvement plan. A PIP is a formal response to someone falling short of their current role. An IDP is for people doing fine who want to do more. If the two get confused, people start to fear the IDP.
It is also not a training budget request. Courses can be part of a plan, but most growth comes from the work itself: taking on a harder problem, leading something for the first time, teaching others.
Start from the gap, not from a wish list
The best source for an IDP is a check-in: the employee has assessed themselves against the skills their role expects, the manager has done the same, and both have seen where the ratings differ or fall short of the level. Those gaps are the raw material.
Pick one or two of them. Choose by asking:
- Which gap matters most for the next level? Read the next level's expectations and find the biggest jump.
- Which one does the person care about? A plan the person is not interested in will not get done.
- Is there work coming up that would help? A gap that the next quarter's work can close is the easiest to act on.
Without a career ladder, you can still write an IDP, but the goals tend to drift towards whatever sounds good — "become more strategic" — rather than what the role needs. Clear expectations per level make the plan much easier to write.
How to write an action that gets done
Most IDPs fail at this step. "Improve communication skills" is a wish, not an action. A good action answers five questions:
- What exactly will you do? A verb and a deliverable.
- Which skill does it build? One skill from the role, or a broader goal if it does not fit one.
- How will we know it is done? A finish line both sides can see.
- By when? A real date, a few weeks to three months away.
- What support is needed? Time, access, a mentor, a budget, an introduction.
Compare:
| Vague | Concrete |
|---|---|
| Get better at public speaking | Present the quarterly support report at the all-hands meeting in December; rehearse once with the team lead first |
| Learn more about the product | Shadow two onboarding calls with the solutions team by the end of the month and write up three questions customers ask |
| Take on more responsibility | Own the release checklist for the next two releases, including the go/no-go call |
Mix the kinds of action. A useful balance is mostly doing (a stretch assignment on real work), some learning from others (shadowing, mentoring, feedback) and a little formal learning (a course or a book) — not the other way round. A plan made only of courses produces certificates, not new behaviour.
An IDP template
Copy this into whatever tool you use. It fits on one screen, which is the point.
Person / role / level: name — role — current level
Direction: for example, "ready for level 3 within 12 months" or "move into the management track"
Focus skills: one or two, from the role's expectations
| Action | Skill | Done when | Due | Support needed |
|---|---|---|---|---|
| What you will do | Skill name | Visible finish line | Date | Time, mentor, etc. |
Reviewed at: the next check-in, date
Keep two to four actions open at a time. When one is finished, add the next instead of writing ten up front.
Examples for four roles
Customer support specialist, level 2 3
Direction: become the person others rely on in one complex area. Focus skills: product and technical knowledge, support operations. See the customer support template for the level expectations.
| Action | Skill | Done when | Due |
|---|---|---|---|
| Write internal notes for the five most common billing issues | Product and technical knowledge | Notes published; two colleagues have used them | 6 weeks |
| Run a 30-minute team session on billing configuration | Product and technical knowledge | Session held, questions collected | 10 weeks |
| Propose one change to the escalation process, based on last month's tickets | Support operations | Proposal discussed with the support lead | 12 weeks |
Account executive, mid-level senior
Direction: handle larger, multi-stakeholder deals on their own. Focus skills: discovery and qualification, deal management and closing. See the account executive template.
| Action | Skill | Done when | Due |
|---|---|---|---|
| Lead discovery on two deals with three or more stakeholders, manager observing | Discovery and qualification | Two calls led, feedback written after each | 8 weeks |
| Write a mutual action plan for each active deal over a set size | Deal management and closing | Plans shared with the customer and kept current | Ongoing, review in 12 weeks |
| Ask two colleagues who joined those calls for written feedback | Discovery and qualification | Feedback received and discussed at the check-in | 10 weeks |
Software engineer, level 2 3
Direction: senior engineer within a year. Focus skills: system design, mentoring and team growth. See the software engineer template.
| Action | Skill | Done when | Due |
|---|---|---|---|
| Write the design document for the reporting export, and run its review | System design | Document reviewed by two senior engineers and approved | 6 weeks |
| Pair weekly with the newest engineer on the team | Mentoring and team growth | Eight sessions held; the new engineer ships their first feature alone | 10 weeks |
| Review pull requests outside your own area at least twice a week | System design | Habit kept for a full quarter | 12 weeks |
New engineering manager, first six months
Direction: run the team without stepping back into individual work. Focus skills: people development, delivery and execution. See the engineering manager template.
| Action | Skill | Done when | Due |
|---|---|---|---|
| Hold a career check-in with every direct report | People development | All check-ins completed, each with agreed actions | 8 weeks |
| Hand the on-call rotation and the release checklist to two team members | Delivery and execution | Both run them without you for a full month | 12 weeks |
| Meet a more experienced manager every two weeks | People development | Six meetings held; one change made to how you run 1:1s | 12 weeks |
Notice what the examples have in common: almost every action is real work the person would partly do anyway, made deliberate and given a finish line.
Keeping the plan alive
A plan that is written and filed is forgotten within a month. Three habits keep it alive:
- Review it at every check-in. Start each check-in with the open actions: what got done, what is stuck, what no longer makes sense. Cancel actions that have lost their point — that is honest, not a failure.
- Write progress down as it happens. A short note when something moves — "first session held, 6 people attended" — beats trying to remember three months later, and it becomes evidence for a promotion case.
- Let the employee close the action. The person doing the work says when it is done, with a note on how it went. The manager can disagree and reopen it, but should not tick boxes on someone's behalf.
Due dates only work if someone notices them. If your plan lives in a document, put the dates in a calendar. In LadderKit, each IDP item is a growth action with a due date, an optional link to a skill from the person's role, a notes thread both sides write in and reminders before and after the due date; only the employee can mark it complete.
Common mistakes
- Too many goals. Two focus skills, two to four actions. Everything else waits.
- Actions without a finish line. If you cannot tell whether it is done, it will never be done.
- Only courses. Learning happens in the work; courses support it.
- Written by the manager alone. The person has to recognise it as their plan.
- Disconnected from the role. Goals that do not point at the next level's expectations do not help with promotion, and people notice.
- Never revisited. An IDP that is not discussed at the next check-in was a formality.