Purpose

The PDP exists to give structure to growth. It turns the ambiguous desire to "get better at things" into a set of specific goals with clear actions, defined support, and honest review.

Its purpose is:

• To make development intentional rather than accidental
• To connect what the person wants with what the organisation needs
• To give the manager a clear commitment of what they will do to help
• To create a shared reference point for progress conversations

What it is not for:

• Ticking the HR box that says "development plan completed"
• A list of courses and certifications
• Covering the manager's position if the person later underperforms
• Replacing genuine development conversations with a document

Most PDPs fail at the point of creation. They are filled in during a meeting because HR has said everyone needs one. They contain vague goals like "improve communication skills" with actions like "complete the communication training module." Six months later, nobody looks at them.

A real PDP starts with a real conversation.

The critical distinction: A PDP is a voluntary development tool for someone performing at or above expectations who wants to grow. It is not a corrective tool. If someone is underperforming, they need a performance conversation and potentially a PIP - not a PDP. Conflating the two undermines both.

When to Use This Playbook

Triggers:

• After a performance review - the review identifies development direction and the PDP gives it structure
• When someone explicitly expresses a career or development ambition
• When a person is at a decision point - they are ready to step up, or they want to shift direction
• At the start of a new year or half-year cycle
• When someone has just started a new role and needs structured onboarding goals

Cadence:

• PDP creation: once per cycle (annual or semi-annual), or when a significant change happens
• PDP review: monthly minimum - this is a live document, not an annual artefact
• PDP update: as needed when goals evolve, circumstances change, or actions are completed

Who initiates:

Either party can initiate. Ideally the person initiates - that signals ownership. But if they have not brought it up and you think they should have one, raise it. "I'd like us to have a more structured development conversation. Are you open to building a PDP together?"

Before You Start

• Review the outcome of the most recent performance review - what development directions came out of it?
• Think about what you know of their career aspirations - what have they said in 1:1s about where they want to go?
• Look at the level above their current level - what does that look like in your organisation?
• Think about what the organisation needs in the next twelve months - are there opportunities that align with their development?
• Be clear in your own mind about what you can genuinely commit to - mentoring, project exposure, introductions, time. Do not promise what you cannot deliver.
• Set aside at least 60 minutes for the PDP conversation - this cannot be rushed into the last ten minutes of a 1:1

Ask the person to reflect in advance:

Send them a brief prompt a few days before the conversation. Something like:

"Before we meet to work on your PDP, it would be useful if you could spend a few minutes thinking about: what you're most proud of right now, where you feel stretched or frustrated, what kind of work you'd like to be doing more of, and where you want to be in two to three years. We'll start from your answers."

The PDP Conversation

This is a conversation, not a form-filling exercise. The document gets written after the conversation, or together during it - but the thinking happens through dialogue, not dictation.

The three questions that drive the conversation

1. Where are you now?

Not a performance rating - a genuine exploration of how the person sees their current state. What are they confident in? Where do they feel uncertain? What are they finding harder than they expected?

Questions to ask:

• "When do you feel most in your element at work?"
• "When do you feel most stretched or out of your depth?"
• "What do you wish you were better at?"
• "What do people come to you for? What do they not come to you for that you wish they would?"

2. Where do you want to go?

This is the most important question and the one most managers skip or rush. Give it time. The answer is often uncertain, especially for people earlier in their careers.

Questions to ask:

• "Where would you like to be in three years? What does good look like for you then?"
• "What kind of problems do you want to be solving?"
• "Is there someone doing a job that you look at and think 'I'd like to do that'?"
• "Is there something you've always wanted to try but haven't had the opportunity?"
• "What would you regret not having tried in your career?"

Accept ambiguity. Not everyone knows exactly where they want to go. If they say "I'm not sure," explore it rather than rushing past it. "That's completely fine - what directions feel interesting, even if you're not sure about them yet?"

3. How do we close the gap?

Once you have a reasonably clear picture of current state and direction, move to the practical question. What needs to happen to get from here to there?

Questions to ask:

• "What's the biggest gap between where you are now and where you want to be?"
• "What would you need to learn or experience to get there?"
• "Who do you know who has made that transition? What could you learn from them?"
• "What's in your way that I can help with?"

The Template Structure

A PDP should be short enough to use and specific enough to be useful. A good one fits on two pages.

Section 1 - Current state (1 paragraph)

In their words: what they are doing well, where they are stretching, what they find hard. Written by them, not about them.

Section 2 - Target state (1 paragraph)

Where they want to be in twelve to twenty-four months. Job level, type of work, skills, impact. Specific enough to know when they are getting closer.

Section 3 - Development goals (maximum 3)

Three goals maximum. More than three and none of them get real attention. Each goal follows this structure:

Section 4 - Support needed from manager

Explicit. Not implied. This is the manager's commitment: specific introductions, time for coaching, project exposure, feedback, advocacy. Name it.

Section 5 - Review dates

Monthly minimum. Put them in the calendar now.

How to Set Goals That Are Specific Enough to Be Useful

Most development goals fail the specificity test. They are written at a level of abstraction that makes progress invisible.

Before and after examples:

The test: if you read the goal in six months, will both parties immediately know whether it has been achieved?

The four elements of a useful development goal:

1. What - specific skill, behaviour, or capability to develop
2. How much - some measure of what "better" looks like
3. By when - a deadline or checkpoint
4. So that - the reason it matters (connection to the target state)

The Monthly Review

Book these now. Do not rely on fitting the PDP into the standard 1:1 every month - it will always be displaced by the immediate.

A monthly PDP review takes fifteen to twenty minutes and covers:

• What progress has been made on each goal since last review?
• What actions were committed to - were they completed? If not, why not?
• Is there anything getting in the way that the manager can help with?
• Does anything need to change - are the goals still right, are the actions still the right ones?
• What is the commitment for the next month?

Keep a brief record of each review against the PDP document. Over six months, this record tells the story of the development journey.

How to Tell If a PDP Is Working

Signs it is working:

• The person refers to it unprompted
• Actions are being completed between reviews
• You can see visible change in the behaviours or skills the goals target
• The person can tell you what they are working on and why
• They are seeking out the experiences and inputs the plan identifies
• The manager is following through on their committed support

Signs it is not working:

• The PDP was last opened the month it was created
• The goals feel abstract at every review - no visible movement
• The actions are perpetually "in progress" without completion
• The person has mentally moved on - their interests have shifted but the plan has not
• The manager's committed support has not happened

If it is not working, do not pretend otherwise. Name it: "I think this PDP isn't actually driving anything for you right now. Let's talk about why and decide whether to rework it or do something different."

When Progress Stalls

Progress stalls for a predictable set of reasons:

The goal is wrong. The person set a goal because it seemed like the right answer, not because they genuinely care about it. The fix is to revisit the "why" - does this goal still connect to something real? If not, change it.

The actions are too big. A goal with one massive action (e.g. "lead a major cross-team project") can stall when that project does not materialise. Break it into smaller, controllable actions.

Life got in the way. The person has been flat out and development has dropped down the priority list. Acknowledge this - it happens. Ask what one small thing they could do in the next two weeks to keep the thread alive.

The manager has not held up their end. The committed support has not happened. Name it and repair it: "I said I would [X] and I haven't done it. I'm sorry - I'm going to do it this week."

The goal was never realistic. The target state requires an opportunity that does not currently exist in this organisation. This is a harder conversation - see the section in the Career Conversations playbook on ambition that does not fit the current org.

PDP vs PIP - the Critical Difference

This distinction matters. Confusing the two causes harm.

Never frame a PIP as a PDP. It is dishonest, and people see through it immediately.

What Good Looks Like

• The person owns the PDP - they bring it to reviews, they refer to it, they update it
• The goals are specific enough to generate clear actions
• The actions are being completed, not just recorded
• The manager has followed through on their committed support
• Progress is visible - not just on a document, but in the person's actual work and capability
• By the end of the cycle, the person can point to concrete evidence of growth

Common Failures

Failure 1 - The form-filling exercise

What it is: The PDP is created because HR requires it. Both parties spend thirty minutes filling in a template. It is filed. It is never opened again.

Why it happens: The conversation was not had. The PDP was treated as the destination rather than the output of a real development dialogue.

What to do instead: Start with the conversation. Use the questions in this playbook. Let the document emerge from the dialogue, not precede it.

Failure 2 - Too many goals

What it is: The PDP has six development goals covering every dimension from technical skills to stakeholder management to presentation skills to strategic thinking.

Why it happens: The manager and the person try to cover everything. Everything feels important.

What to do instead: Three goals maximum. Ask: "If you could only develop one thing this year that would make the biggest difference, what would it be?" Start there. Add a second. Consider whether a third is genuinely needed.

Failure 3 - Vague goals with no success criteria

What it is: "Develop leadership skills." "Improve technical depth." "Build cross-functional relationships."

Why it happens: It is easier to write a vague goal than a specific one. Specific goals can be evaluated, and that feels exposing.

What to do instead: Apply the four-element test to every goal. If you cannot write a success criterion that both parties would agree on, the goal is not ready yet.

Failure 4 - Manager commitment that does not happen

What it is: The plan says "manager will provide introductions to the platform team" or "manager will create opportunity for [person] to lead the next architecture review." Six months later, none of it has happened.

Why it happens: Good intentions, competing priorities, forgetting.

What to do instead: Write your commitments down and put actions in your own calendar. At every PDP review, check your own commitments before the person's. If you have not followed through, say so and repair it immediately.

Failure 5 - Treating it as an annual document

What it is: The PDP is created at the start of the year and reviewed once, at the year-end review.

Why it happens: The cadence was never set up. Monthly reviews were not booked.

What to do instead: Book the monthly reviews now, before you finish the PDP conversation. Put them in the calendar as a fixed series. Protect them.

Checklist

Before the PDP conversation:

• Reviewed the performance review outcomes
• Thought about what I know of their career aspirations
• Reviewed the next-level expectations for their role
• Identified what I can realistically commit to in terms of support
• Sent them a reflection prompt in advance
• Booked at least 60 minutes for the conversation

During the PDP conversation:

• Asked "where are you now?" and listened properly
• Asked "where do you want to go?" and gave it real time
• Explored the gap between current and target state
• Agreed no more than three goals
• Applied the specificity test to each goal
• Written explicit success criteria for each goal
• Committed explicitly to what I will do to support each goal
• Agreed review dates and booked them in the calendar

After the PDP conversation:

• PDP document updated and shared with the person
• Monthly review sessions in the calendar
• My own commitments in my calendar with reminders
• First monthly review completed within 30 days

At each monthly review:

• Checked my own commitments first
• Reviewed progress on each goal
• Reviewed completion of actions
• Updated the PDP document with progress notes
• Agreed next month's actions
• Checked: do the goals still feel right?

The Manager's Role in Development

A PDP is a tool. The manager is the engine.

The document cannot do the work - it can only structure it. What actually drives development is the manager's ongoing attention, access to opportunities, quality of feedback, and willingness to advocate.

What great development managers do:

• Create stretch opportunities before the person is ready - not reckless exposure, but deliberate challenge just beyond the current comfort zone
• Debrief after high-stakes moments - not just "how do you think it went?" but detailed, specific feedback that builds the person's self-awareness
• Make introductions - to people, to communities, to problems the person would not otherwise encounter
• Advocate internally - in calibration sessions, in conversations with your own manager, when opportunities arise that would fit the person's direction
• Connect what the person is doing to the bigger picture - help them see how their development connects to what the organisation values and needs

What development managers should avoid:

• Using "development" to fill someone's plate with tasks that serve the team's needs and are dressed up as growth opportunities
• Providing learning resources as a substitute for real experience
• Treating the PDP as a performance management tool - the moment it starts to feel like measurement rather than investment, the person will disengage

The honest question to ask yourself quarterly:

"What have I actually done in the last three months to actively develop this person?"

If the answer is "I reviewed the PDP with them and encouraged them," that is not enough. Development requires active investment - not passive oversight.

When Development Goals Conflict with Team Needs

This happens. Someone wants to develop in a direction that takes them away from the work the team most needs them to do.

Examples:

• A strong individual contributor who wants to move into people management - but you need their technical depth right now
• An engineer who wants to specialise in infrastructure - but the team's priority is product delivery
• Someone who wants to reduce their scope to go deep in one area - but you need breadth coverage

Be honest about the tension rather than pretending it does not exist.

"I want to be straight with you. The direction you want to move in is going to create some tension with what I need from the team right now. I think we can find a way through it, but I don't want to promise you development opportunities and then not be able to deliver them. Let's talk about what's realistic."

Then find a genuine path - even if it is slower or less complete than the person would like. A partial development opportunity that is real is worth more than a full development promise that evaporates.