The relationship between a Personal Development Plan and a Performance Improvement Plan is sequential and, when the system is working, the PIP should rarely be needed. The PDP is a development tool, used proactively and regularly with engineers at all levels, helping them grow their capability and contribution. The PIP is a formal process, used when performance has fallen persistently below expectations and earlier interventions have not produced the required change.

Most organisations use neither well. PDPs are produced at the start of the year, filed, and never reviewed. PIPs arrive as a surprise to the recipient because the performance conversations that should have preceded them never happened. The formal process becomes both the first honest conversation and the last chance - which is neither fair to the individual nor effective as a performance management mechanism.

This section is about using both tools correctly. That means using PDPs as genuine development instruments and PIPs as honest, structured interventions of last resort rather than managed exits in disguise.

What a PDP Is (and Is Not)

What It Is

A Personal Development Plan is a structured agreement between an engineer and their manager about what the engineer wants to develop, how they plan to develop it, what support they need, and how they will know they have made progress. It is forward-looking. It is specific. It is co-created. And it is reviewed regularly.

The PDP exists to serve the engineer's development. That development may align with the organisation's needs - and it should, because development that has no value to the current role is not well-targeted - but the primary beneficiary is the individual. A PDP that the engineer has not genuinely bought into is not a PDP, it is a form.

What It Is Not

Not a performance review. The PDP is about where the engineer is going, not where they have been. A PDP meeting that becomes a review of past performance has lost its purpose.

Not a list of training courses. "Will attend Kubernetes training in Q2" is an activity. It is not a development goal. A development goal is an outcome: "By end of Q2, I will be able to design and review container orchestration configurations for our production services without external support." The course might be one step toward that outcome, but the outcome is the goal.

Not an annual document. A PDP that is created in January, reviewed in December, and ignored in the intervening eleven months is a compliance exercise. Development goals that are not reviewed regularly are not goals - they are aspirations that have been recorded.

Not imposed. A manager who hands an engineer a PDP with goals already filled in has confused development planning with performance management. The engineer must own the plan for it to be worth anything.

What Makes a PDP Work

Specific Outcomes

"Improve my technical skills" is not a development goal. "Develop enough understanding of our observability stack that I can independently diagnose production performance issues without escalating to senior engineers" is a development goal. The difference is specificity: a specific goal makes it possible to know whether progress has been made.

Development goals should be expressed in terms of what the engineer will be able to do, at what level of independence, in what context. The SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound) is overused to the point of parody but is structurally sound. The M and the T are the most commonly omitted: how will we know the goal has been reached, and by when.

Manager Commitment to Enabling Development

A PDP without a corresponding commitment from the manager is a wish list. If the engineer has identified a goal that requires exposure to a particular type of work, the manager needs to create or find that opportunity. If the goal requires mentoring from a particular person, the manager needs to facilitate that relationship. If the goal requires time away from delivery work for learning, the manager needs to protect that time.

Manager commitment to enabling development is the most commonly missing element of a PDP. The form is completed, the goals are agreed, and then the engineer is expected to develop while the manager continues to fully utilise their capacity on delivery. This does not work. Development requires investment - of time, attention, and sometimes opportunity cost.

Regular Review

Development goals should be discussed at least monthly - briefly, as a standard element of the 1:1 agenda. The review should cover:

• What has the engineer done toward this goal since last time?
• What progress are they making?
• What is getting in the way?
• What does the manager need to do differently to support progress?

A brief conversation monthly is worth infinitely more than a comprehensive conversation annually. The monthly conversation allows course correction, catches blockers early, and signals that the plan is real and taken seriously.

Connected to Career Direction

The most motivating development goals are ones that the engineer can connect to where they want their career to go. A goal that is purely organisationally valuable but personally irrelevant may be completed but will not be pursued with much energy. The manager's job in PDP conversations is to understand what the engineer actually wants from their career and to find the overlap between that and what the organisation needs.

A PDP Template That Works

The following template is deliberately simple. Complexity is the enemy of regular use.

Personal Development Plan

Name: [Engineer name] Manager: [Manager name] Period: [Quarter or year - prefer quarterly] Review dates: [Specific dates, not vague]

Current State

What I am good at right now, and where I have impact:

(The engineer writes this. The manager adds perspective where it differs.)

What I find difficult, or where I am less effective than I want to be:

(Honest and specific. This is the development starting point.)

Where I Want to Get To

What kind of engineer do I want to be in 12-18 months?

(Career direction, not just skill list. What is the motivating picture?)

What role or type of work am I aiming toward?

(Informed by the career and capability framework.)

Development Goals This Period

Maximum three goals per period. If there are more than three, the plan is unfocused.

Manager Commitments

What I (manager) commit to doing to support these goals:

(Specific, not generic. "I will prioritise opportunities for X to lead the next architecture review" not "I will support your development.")

Review Log

End of Period Assessment

What was achieved? What changed? What carries forward?

This template should take thirty to forty minutes to complete together at the start of a quarter. It should take five to ten minutes to review each month. If it is taking longer than that, it is too complicated.

What a PIP Actually Signals

By the time a formal Performance Improvement Plan is the appropriate intervention, something has gone wrong earlier in the process. Not necessarily in the formal process - often the formal process is being initiated correctly. What has gone wrong is that the conversations, observations, and interventions that should have preceded the formal process either did not happen or did not produce change.

The PIP is rarely the first intervention it should be. In most cases, it is:

• The first honest conversation the engineer has had about their performance
• The first time expectations have been made explicit in writing
• The first time consequences have been named clearly

This is a management failure, not just a performance failure. It does not mean the PIP is wrong. It means the situation has been allowed to develop to the point where the formal process is the only tool available. Addressing that failure pattern requires building the culture of continuous feedback and early intervention described elsewhere in this section.

A PIP also signals something about the manager's confidence in the outcome. A PIP that is genuinely designed to support improvement is different in character from a PIP that is a managed exit - a documented process whose purpose is to establish grounds for dismissal rather than to support the engineer in meeting the required standard. Both exist. Both are called PIPs. Only one is honest.

When a PIP Is Appropriate

A PIP is the right tool when all of the following are true:

1. The performance gap is real and persistent. The engineer is not meeting the expectations of their role in ways that matter - quality, delivery, collaboration, or some combination. This is not occasional underperformance or a bad patch. It is a pattern that has continued despite earlier conversations and support.

2. The expectations have been made explicit. The engineer knows what is expected of them. The expectations have been written down and discussed. "Meets expectations" has been defined. The gap between current performance and required performance is clear to both parties.

3. Earlier conversations have happened and have not produced sufficient change. The PIP is not the first intervention. There have been development conversations, coaching conversations, or an informal performance conversation. Support has been offered and provided. The performance has not improved to the required level.

4. The performance issue is not a conduct or capability matter requiring a different process. PIPs address performance (doing the job at the required standard). Conduct issues (behaviour that breaches professional standards or team norms) require a different process. Fundamental capability issues (the person does not have and cannot develop the skills required for the role) may require a redundancy or redeployment process rather than a performance process. Confusing these categories creates legal risk and unfair treatment.

5. Genuine support is available and will be provided. A PIP that nominates support but does not provide it is not a good faith process. If the manager cannot genuinely commit to the support required, the process should not proceed until that changes.

How to Run a PIP With Integrity

A PIP run with integrity has the following characteristics:

Honest About the Situation

The conversation that opens a formal PIP should be direct. Not unkind, but clear. The engineer should leave that conversation knowing:

• That this is a formal process
• What the specific performance concerns are (with evidence)
• What improvement is required, in concrete terms
• What the timeline is
• What happens if the required improvement is not achieved
• What support will be provided

Softening the message to the point where the engineer does not understand the seriousness of the situation is cruel disguised as kindness. It deprives them of the information they need to make informed decisions about their situation.

Clear Success Criteria

The PIP must specify what improvement looks like. Not "improve communication" but "PR descriptions consistently include context, rationale for approach, and testing notes, as assessed by reviewers over the next eight weeks." Not "deliver more consistently" but "all sprint commitments completed within the sprint or exceptions flagged in advance over the twelve-week period."

Success criteria that cannot be objectively assessed are not success criteria. They are traps - because the manager can then declare the PIP not met for subjective reasons that the engineer cannot challenge.

Genuine Support, Not a Managed Exit in Disguise

A PIP designed to support improvement will:

• Provide the specific support nominated (coaching, pairing, training, reduced scope while development happens)
• Allow sufficient time for genuine improvement to be demonstrated (six to twelve weeks is typical; less than that is usually too short to observe meaningful change)
• Celebrate genuine progress and adjust the assessment accordingly
• End early if the required standard is met ahead of schedule

A PIP designed as a managed exit will:

• Set success criteria that were never achievable in the timeframe
• Provide notional support that is not meaningful
• Maintain a fixed narrative of failure regardless of evidence of improvement
• Use the documentation as the primary purpose, not the development

The engineer - and any HR professional or employment tribunal reviewing the process - can usually distinguish between these. Running a PIP as a managed exit is unfair to the individual and risky for the organisation.

Checkpoint Conversations

The PIP period should include regular formal checkpoints - weekly or fortnightly depending on the timeline. At each checkpoint:

• Review progress against the specific success criteria
• Provide specific feedback on what is going well and what is not
• Adjust support if what was planned is not working
• Document the conversation

Do not wait until the end of the PIP period to tell the engineer whether they are on track. Regular checkpoints allow genuine course correction and demonstrate good faith.

The Bridge Between PDP and PIP

The space between "performing well, focused on development" and "formal performance process" is where most of the work should happen. Most organisations jump from one to the other with nothing in between.

The bridge is the early intervention conversation - a clear, honest, informal conversation when performance first begins to show signs of concern. This conversation is not a PIP. It is not a formal process. It is a manager fulfilling their responsibility to name something clearly before it becomes a formal issue.

An early intervention conversation should include:

A specific description of the concern. "I've noticed over the last six weeks that your PR quality has declined. The last three have come back with significant issues after review, and the testing coverage has been sparse. I want to understand what's happening and make sure we address it."

An invitation to share context. "Is there something going on that I should know about? Are there things that are getting in the way?" The answer to this question may reveal a system problem (unclear requirements, overload, missing context), a personal circumstance (health, family, wellbeing), or confirm that this is a performance issue requiring direct support.

Clear expectation-setting. "What I need to see over the next four weeks is... [specific, observable standard]."

Offered support. "What would help you get there? I can [specific support options]."

A follow-up date. "Let's revisit this in four weeks and see where we are."

This conversation is documented - the manager writes a brief note of what was discussed, what was agreed, and when the follow-up is scheduled. The documentation is not shared with HR unless the situation escalates. It is the manager's record that the conversation happened.

If the early intervention produces the required change, nothing further is needed. If it does not produce sufficient change after two or three iterations of this conversation and support, the situation may warrant a more formal process. But the formal process should never be the first honest conversation.

Common Failures

PDPs That Are Never Reviewed

The PDP that exists as a document but is never discussed is worse than useless - it is a fiction that occupies time at the start of the year and generates false confidence that development is happening. If a PDP review is not a standing agenda item in the manager's 1:1, it will not happen. Put it on the agenda. Every month. Briefly.

PIPs That Surprise the Recipient

If an engineer receives notification that a formal PIP is being initiated and is genuinely surprised by the seriousness of the situation, the performance management system has failed. Either:

• The earlier conversations did not happen
• The earlier conversations happened but the seriousness was not communicated clearly
• The earlier conversations happened clearly but the documentation does not reflect it

In any of these cases, the PIP starting from a position of surprise is unfair to the engineer and weak as a management process. Surprise at a PIP should be treated as a serious signal about the quality of preceding performance management.

Conflating Performance With Personality

"She is not really a team player." "He is not very proactive." "She lacks executive presence."

These are personality characterisations. They are not performance assessments. If an engineer's performance is being questioned, the concerns need to be expressed in terms of observable behaviours and their impact, not character judgements.

Performance that is assessed in personality terms cannot be improved because the engineer does not know what to do differently. "Be more proactive" is not an action. "In sprint planning, identify and raise blockers before the team picks up the work" is an action. The difference between performance management and character assassination is specificity.

Using the PDP to Surface Development-Away

Occasionally, a PDP is used to guide an engineer toward development that would make them suitable for a different role - because the manager has decided they are not right for this one, but does not want to have that conversation directly. This is dishonest and ultimately cruel. If a manager believes an engineer is in the wrong role, that conversation should be had directly, with appropriate support for identifying a better fit. Disguising it as development planning wastes the engineer's time and erodes trust when they eventually understand what was happening.

Connection to Your Operating Model

PDPs and PIPs sit at the intersection of several interconnected systems:

The capability framework. PDPs should be built against the capability framework at the engineer's level. The framework defines what "good" looks like at each level and what development toward the next level requires. Without this reference point, development goals are arbitrary.

The performance conversation cadence. PDPs are only effective within a performance management rhythm that includes regular check-ins and monthly development conversations. Without that rhythm, the PDP is an annual document rather than a living plan.

Feedback systems. PDPs identify development goals. Feedback is the primary mechanism by which progress toward those goals is tracked. The two systems are interdependent - a PDP without feedback is a plan without measurement.

Talent review and calibration. PDP progress is relevant information for talent reviews. An engineer who is consistently making progress against development goals and approaching the next capability level is different from one who has the same goals quarter after quarter without movement. Calibration sessions should be informed by PDP data, not just recent performance impressions.

HR process. The PIP connects to the formal HR process. Managers initiating a PIP should be working closely with HR from the start, not after the fact. HR's role is to ensure process fairness, legal compliance, and consistency across the organisation. Involving them early prevents the process from becoming a series of correctable errors.

This section connects directly to: Modern Performance Management, Feedback Systems, Addressing Underperformance, and the Career and Capability framework.

Making PDPs Work in Practice

The template above provides the structure. The following guidance addresses the practical challenges that prevent PDPs from being used effectively.

The Quarterly Rhythm in Practice

Moving from annual PDPs to quarterly development planning is the single most impactful change most organisations can make. Annual plans become irrelevant within weeks of being written. Quarterly plans stay connected to the current reality of the person's role, their current challenges, and the organisation's current priorities.

A quarterly PDP rhythm looks like:

Week 1 of the quarter: Manager and engineer spend 30-40 minutes reviewing the previous quarter (what was achieved, what changed, what was learned) and agreeing the goals for this quarter. The engineer drafts the goals between sessions; the manager refines them in the meeting.

Weeks 4 and 8: Brief progress check in the regular 1:1 (ten minutes). Identify blockers. Adjust if circumstances have changed significantly.

Week 12: End-of-quarter reflection (20-30 minutes). What was achieved? What was learned? What carries forward? Feed into next quarter's plan.

This is four conversations per year that are explicitly development-focused, totalling roughly two hours per engineer. That investment, made consistently, produces more development progress than an annual PDP that is completed once and ignored.

When Development Goals Conflict With Delivery Demands

The most common reason development goals are not achieved is that delivery pressure consistently wins the priority contest. This is a management problem, not an engineer problem.

The manager who allows a development goal to be deferred quarter after quarter because "there is always something urgent" is not protecting the engineer's development. They are making a succession of small decisions that collectively signal that development is not a real priority.

Development goals that require protected time - learning time, project assignments, mentoring relationships - need to be treated with the same seriousness as delivery commitments. If a delivery commitment slips, the manager acts. If a development commitment slips, the same standard should apply.

Practically, this means:

• When planning a sprint or quarter, block time for development activities rather than filling capacity 100% with delivery
• When development time is threatened by an urgent delivery demand, have an explicit conversation about the trade-off rather than silently deprioritising the development
• Track development goal progress in the same way delivery commitments are tracked - visibly and with consequences for slipping without explanation

Goal Setting Conversation Guide

The PDP goal-setting conversation is often done poorly because managers do not know how to guide engineers through it. The following prompts help:

Opening: "Before we talk about what you want to develop, I want to understand what you want your engineering career to look like. Not necessarily in this organisation - just in general. What kind of work do you want to be doing in three years?"

Identifying development needs: "Given that direction, what are the things you need to get better at? What do you find most difficult right now? Where do you feel less confident than you'd like to?"

Sharpening goals: "You've said you want to get better at system design. What would you be able to do, that you can't do now, if you'd made the progress you wanted? How would we know you'd got there?"

Adding the organisational dimension: "Where does the organisation need you to develop? Are there things your role requires that you're not yet strong in? Are there gaps that are visible to me that you might not be aware of?"

Agreeing support: "What do I need to do to make this possible? What opportunities do you need that you're not currently getting?"

This conversation is not an interrogation. It is an inquiry. The manager's job is mostly to ask good questions and listen, then to help the engineer translate their answers into specific, achievable goals.

Running a PIP That Actually Produces Improvement

Most PIPs do not produce improvement. The reasons are structural:

• The success criteria are unclear or moving
• The support is nominal rather than real
• The timeline is too short for genuine change to occur and be demonstrated
• The manager has already concluded the outcome before the process begins

A PIP that is designed to produce improvement rather than manage a departure has the following characteristics:

Characteristics of a Genuine Improvement PIP

Success criteria that the engineer helped define. The engineer should have input into what "meeting expectations" looks like during the PIP period. Not unlimited input - the manager sets the standard. But the engineer should be able to say "yes, if I achieve that, I should be considered to have met the requirement."

A realistic timeline. Behaviour change, skill development, and demonstration of sustained improvement take time. A four-week PIP where the expectation involves demonstrating pattern change is almost certainly too short. Eight to twelve weeks allows for meaningful observation across a representative sample of work.

Named support that is actually delivered. "Will be paired with [name] on [project]" and that pairing actually happens. "Will receive weekly coaching sessions with [name]" and those sessions happen on schedule. If the support does not materialise, the PIP cannot be validly assessed as not met - the organisation failed its part.

Genuine positive recognition during the process. When improvement is observable mid-PIP, name it. "I've noticed that your PR descriptions have significantly improved over the last three weeks - that is exactly what I was asking for." A PIP where only failures are noted and successes are ignored is not a genuine improvement process.

Regular, documented checkpoints. Weekly for shorter PIPs, fortnightly for longer ones. Each checkpoint should assess progress against the specific criteria, not against a general impression.

The Checkpoint Conversation Structure

At each checkpoint during a PIP:

Review evidence. Go through the specific observable criteria. For each one: has there been improvement? What examples support the assessment?

Name what is working. If any criteria are being met, name them specifically. This is not flattery - it is accurate assessment.

Name what still needs work. For criteria not yet met, be specific about what the gap is and what the engineer needs to do in the next period.

Adjust support if needed. If what was planned is not working, say so and adjust. A coaching relationship that is not helping should be changed, not maintained.

Confirm what the next checkpoint will cover. The engineer should leave knowing exactly what they need to demonstrate by the next checkpoint.

When the PIP Is Not Working

Sometimes a PIP does not produce improvement. The honest signals:

• The same issues recur checkpoint after checkpoint despite specific feedback and support
• The engineer is not engaging with the support offered
• The capability gap is more fundamental than the PIP was designed to address

When a PIP is not working, the next step depends on the cause:

If the gap is deeper than expected: Consider whether this is a role fit issue rather than a performance issue. The engineer may be capable but not in this role. A constructive conversation about a different role - internal or external - may be more humane and more effective than continued PIP.

If the engineer is not engaging: This may signal that the engineer has already decided to leave, or that the PIP itself feels like a managed exit and they are not investing in it. A direct conversation - "I want to understand whether you want to stay in this role. If you do, I need to see more engagement with the support we've put in place" - is more honest than continuing through the motions.

If the manager is not delivering the support: The PIP cannot be assessed as failed if the organisation has not met its commitments. This is a management failure that HR should be engaged on.

Reference: PDP vs PIP Comparison

The most important thing this comparison illustrates: these are different tools for different situations. Using a PIP as a development tool is inappropriate - it carries the weight of a formal process and the implied threat of consequence, which is incompatible with the psychological safety that development requires. Using a PDP to address serious underperformance is inappropriate - it lacks the seriousness and structure that the situation requires. Use the right tool.

Reference: Questions for the PDP Review Meeting

Use these questions to structure the monthly PDP review:

Looking back:

• What have you done toward your development goals since last time?
• What has worked? What has not?
• What got in the way?
• What have you learned - about the goal, about yourself, about the work?

Looking forward:

• What will you focus on before we next meet?
• What do you need from me?
• Is there anything about the goals that should change given what has happened?

Manager reflection:

• Have I delivered the support I committed to?
• Is there anything I am seeing that should inform the goals?
• Am I creating the conditions for this development to happen?

A review meeting that covers all of these questions in ten minutes has done its job. A review meeting that covers none of them has not happened in any meaningful sense, regardless of what the calendar says.