The Individual Development Plan Playbook: A Recipe for Development That Actually Happens

Most IDPs get written once, reviewed at the next annual cycle, and treated as a compliance checkbox.

The employee wrote down three things they want to learn. The manager said "great." Both parties signed off. The document lived in an HR system until performance review season, when everyone pretended to remember what it said.

This isn't because development doesn't matter. It's because the IDP process is usually designed to document development, not produce it. There's a difference.

This playbook gives you a 5-step recipe for IDPs that generate real skill growth — not for every employee at once, but for the employees where development matters most right now.

The Recipe at a Glance

Outcome you're trying to achieve: A written development plan with a specific skill target, a concrete practice method, a 90-day check-in built in, and one person who owns accountability (not two people who share it).

Ingredients:

A specific performance observation or goal gap (not a generic "wants to grow in leadership")
A 30-minute development conversation with the employee
A shared writing surface (not email)
One development method with a time commitment
A 90-day checkpoint scheduled before the plan is "done"

When to use this: After any performance review, after a goal gap is identified, when an employee is preparing for a level change, or when a manager wants to invest in someone with high potential.

When NOT to use this: As a response to a performance issue. IDPs are for growth, not correction. Use a performance improvement plan (PIP) for that — different purpose, different process, different stakes.

Step 1: Name the Specific Skill, Not the Category

Most IDPs fail before they start because the development target is too broad.

"Improve leadership skills" is not a development target. "Executive communication skills" is a category. "Stakeholder management" is a department, not a destination.

Before writing anything down, complete this sentence:

By the end of 90 days, [employee name] will be able to [specific behavior] in [specific context] at [specific quality level].

Examples of useful targets:

Too broad	Specific
Leadership skills	Facilitate a cross-functional meeting and hold it to 45 minutes with clear next steps
Communication	Write executive-ready status updates that require no editing before being forwarded
Technical skills	Independently scope and estimate a new API integration without senior review
Strategic thinking	Identify three business risks in a product spec before the engineering kickoff

The employee should help write this sentence. If they can't, the target isn't specific enough yet.

One target per IDP. Not three. If you have three priorities, you have no priorities.

Step 2: Identify the Development Method Before Scheduling the Conversation

Most managers schedule the development conversation, then figure out the plan during it. This produces vague plans.

Before you sit down with the employee, know which development method fits the target:

Practice with feedback — best for behavioral skills (communication, facilitation, leadership). The employee does the real thing repeatedly, with structured feedback after each occurrence. Requires: a regular opportunity to practice, a feedback loop, and willingness to be observed.

Stretch assignment — best for capability gaps (new domain, higher-level responsibility). The employee takes on work slightly above their current level with a safety net. Requires: a real project or responsibility, not a fake one.

Formal learning — best for knowledge gaps (technical skills, frameworks, methodology). A course, certification, or structured reading. Requires: commitment to apply what's learned, not just complete the curriculum.

Mentorship or shadowing — best for tacit knowledge (how to navigate the organization, how decisions actually get made). The employee spends structured time with someone who already has the skill. Requires: a willing mentor and structured debriefs after sessions.

Most development plans benefit from one primary method and one supporting method. Combining three or four methods is a recipe for starting none of them.

Step 3: Run the Development Conversation Around the Plan, Not Before It

The development conversation should happen after you have a draft, not before.

Bring a one-page document with:

The specific skill target (from Step 1)
Your proposed development method (from Step 2)
A rough 90-day timeline
What "good" looks like at 30, 60, and 90 days

Ask the employee three questions:

"Does this target match what you were hoping to work on?"
"What barriers do you see to making this happen — things on your end, things on my end?"
"What would you need from me to make the development method work?"

Then edit the plan together. This takes 20–30 minutes if you've done the prep. It takes 90 minutes and produces vaguer output if you haven't.

The plan is done when:

The employee can explain what they're working on without looking at the document
There's a concrete first action they can take this week
You've scheduled the 90-day check-in before leaving the room

Step 4: Make Accountability Visible, Not Assumed

Development plans die because accountability is shared. When everyone owns it, no one does.

Assign one person to each accountability. Here's how it works in practice:

Employee owns:

Executing the development method (attending training, asking for feedback, completing the stretch project)
Raising blockers when they emerge — not waiting for check-ins
Bringing data to check-in conversations ("here's what I did, here's what I noticed")

Manager owns:

Creating the conditions for practice (assigning work, introductions to mentors, removing blockers)
Providing specific, timely feedback when the employee practices
Not rescheduling the 90-day check-in

Neither person "owns development." They each own their piece.

Write this split into the IDP document. One column for employee actions. One column for manager actions. If a row has both names on it, split it.

Step 5: Check In at 30 Days Before You Check In at 90 Days

Ninety-day plans fall apart because people wait 90 days to see how they're going.

Build a lightweight 30-day checkpoint into every IDP. It takes 15 minutes at the end of a regular 1:1 and answers two questions:

"Have we done the thing we said we'd do?"
"Is the plan still the right plan, or did reality change it?"

At 30 days, most plans need adjustment — not because people failed, but because the initial design missed something. The stretch project scope changed. The mentor moved teams. The employee found a better course than the one originally planned.

Adjusting the plan at 30 days is a sign the process is working. Arriving at 90 days to discover the plan never started is a sign it wasn't.

Track the 30-day check-in in whatever system you use for 1:1 notes. Don't make it a separate meeting — it doesn't need one.

The IDP Template

After completing Steps 1–4, the document should look like this:

Employee: [Name] Manager: [Name] IDP Period: [Start date] – [End date]

Development Target: By [date], [employee] will be able to [specific behavior] in [specific context] at [quality level].

Development Method: Primary: [Practice/Stretch/Formal/Mentorship] — [specific plan] Supporting: [Optional secondary method]

Success Milestones:

30 days: [What should be true]
60 days: [What should be true]
90 days: [What should be true]

Employee responsibilities:

[Specific action 1]
[Specific action 2]

Manager responsibilities:

[Specific action 1]
[Specific action 2]

Checkpoint scheduled: [30-day date], [90-day date]

Common Failure Modes

The plan becomes a report card. The IDP turns into a list of things the employee did wrong. Development conversations should be forward-looking — what they're building, not what they've failed to do.

The target changes three times. Every new project becomes "an opportunity to apply the IDP." This spreads development thin. One target per plan, one development method, one 90-day window. If priorities shift, start a new plan.

The manager sets it and forgets it. The employee executes, checks in, reports back — and the manager has no feedback to give because they haven't been paying attention. The manager's accountability isn't just scheduling check-ins. It's observing the employee's work between check-ins.

"Development" means completing a course. Formal learning is one development method among several, and usually not the highest-leverage one for behavioral skills. If the entire IDP is a course the employee takes online, it's probably not an IDP. It's a training request.

What Good Looks Like at Scale

When IDPs are working across a team, a few things become visible:

Every employee who is up for promotion in the next 12 months has an active IDP targeting the skills required at the next level.

Every employee with a significant performance gap has either an IDP (if the gap is a development issue) or a PIP (if the gap is a performance issue). The manager knows which is which.

Development conversations happen more than once per year. The IDP is a living document, not an annual artifact.

How Confirm Supports This Process

Running IDPs at scale requires a system — somewhere to document the plan, track check-ins, and connect development progress to performance data.

Confirm's performance platform includes tools for documenting development plans, running structured check-in conversations, and tracking development progress alongside goal data and feedback — so development doesn't live in a separate spreadsheet that nobody looks at.

If your team is running IDPs in Word documents and tracking progress in 1:1 notes buried in email, there's a better way.

See how Confirm supports employee development →

FAQ

How many IDPs should a manager run at once?

Most managers can actively support two to four IDPs at a time without the quality degrading. If you're running more than that, you're probably not providing meaningful feedback to each one. Prioritize: who is up for a level change in the next 12 months? Who has a gap that, if closed, materially changes their impact? Start there.

Should every employee have an IDP?

Not necessarily. IDPs are most effective when they're specific and intentional. A blanket policy that every employee has an IDP often produces the compliance-checkbox problem this playbook is trying to solve. Build IDPs where development is the primary lever — for high-potentials on the path to promotion, for employees with specific gaps affecting their performance, and for employees who've explicitly asked for a development focus.

What's the difference between an IDP and a PIP?

A performance improvement plan (PIP) is used when an employee isn't meeting current expectations and the goal is correction. An individual development plan (IDP) is used when an employee is meeting current expectations and the goal is growth. They have different stakes, different processes, and different relationships. Confusing them — using an IDP as a "nice PIP" — damages trust.

How often should the IDP be updated?

The plan itself should be stable for 90 days. The check-ins happen at 30 and 90 days. After each 90-day window, either close the plan (target achieved) or write a new one (new target identified). Don't continuously revise the same plan — it becomes a running document with no clear before/after.