Individual Development Plan: Examples + Template
An individual development plan, often shortened to IDP, is a structured document for identifying development goals, the actions that can support those goals and the evidence you will use to evaluate progress. Depending on the organisation and the situation, an IDP may be created by an employee independently or developed with input from a manager, mentor or another relevant person.
A useful IDP goes beyond listing ambitions. It connects a development area to a specific goal, the actions that address it, the resources or support involved, evidence of progress and a point for reviewing whether the plan is still useful. Not every employer uses IDPs, they are not required of everyone who writes one, and manager involvement is not always part of the process — the format below is a starting structure, not a standard.
Individual Development Plan Example
Here is one complete IDP, filled in the way it would actually be used. The scenario is fictional: a marketing specialist who wants to develop the ability to lead larger cross-functional campaigns. Nothing in it predicts a promotion or a pay change — it is a plan for building a capability, and it stops there.
INDIVIDUAL DEVELOPMENT PLAN — example Name: Priya N. Current role: Marketing specialist, B2B software company Development focus: Leading larger cross-functional campaigns Current strengths: - Campaign copy and messaging, including work used by the sales team. - Reporting on channel performance and explaining what the numbers mean. - Reliable coordination with the design team on individual deliverables. Development area: Running a campaign that spans marketing, product and sales rather than owning one part of it. I have not set a campaign scope, agreed dependencies across teams or chaired a kickoff. Goal: Be able to plan and run one cross-functional campaign end to end — scope, dependencies, schedule, status communication and a documented outcome. Why this matters: Most of the campaigns my team now runs involve at least two other functions, and I am currently contributing pieces rather than holding the plan together. Actions: - Ask to co-own the next cross-functional campaign with the current campaign owner. - Write the scope and dependency list myself and review it with the owner before it is shared. - Chair the kickoff meeting and run the weekly status update. - Sit in on two campaigns led by an experienced owner and note how scope disagreements are handled. - Take a short structured course on campaign planning only if a specific gap remains after the first campaign. Resources/support: - Current campaign owner as an informal mentor. - Manager's agreement on time allocation. - The existing campaign brief and reporting templates already used by the team. Evidence of progress: - A scope document I wrote that was used without major rework. - A kickoff I chaired and six status updates delivered to a mixed audience. - Written feedback from the campaign owner and from one person outside marketing. - A close-out summary recording what was delivered and what I would change. Target/review point: Campaign close, or three months from today if the campaign runs longer. Potential obstacles: The campaign may be delayed or reassigned; a quarter-end push may reduce available time; co-ownership depends on my manager and the current owner agreeing. Progress notes: (To be filled in as actions are completed — what I did, what happened, what was harder than expected.) Next review: At campaign close or at the next development conversation, whichever comes first. Revision trigger: If no suitable cross-functional campaign starts within one quarter, switch the practice opportunity to a smaller internal launch and keep the same goal.
Individual Development Plan Template
Copy this into whatever you write in and fill it in for your own situation. There is no file to download and nothing to sign up for — it is plain text, and it is meant to be edited. A longer version with numbered prompts appears near the end of this guide.
INDIVIDUAL DEVELOPMENT PLAN Name: Current role: Date created: Review date: Current strengths: Development area: Development goal: Why this goal matters: Actions: Resources/support needed: Evidence of progress: Target/review point: Potential obstacles or dependencies: Progress notes: Next action: What would make me revise the plan:
Before you start
An individual development plan is a planning tool, not a promise of promotion, higher pay, a new role or another employment outcome. Organisations use IDPs differently, and the most useful format depends on the person’s role, goals and circumstances. Development actions should address genuine needs rather than simply adding activities to a document.
Key takeaways
- • Start with a real development need rather than an activity you already wanted to do.
- • Document existing strengths as well as gaps — an IDP is not a list of weaknesses.
- • Turn broad ambitions into specific development goals you could start work on this month.
- • Connect each goal to concrete actions that address the actual gap.
- • Identify the resources, opportunities or support the plan depends on, where relevant.
- • Decide in advance what evidence could indicate that progress has happened.
- • Record progress and note when circumstances change — the notes are the useful part later.
- • Revise the IDP when the goal, the context or the evidence changes. A plan you never revise is a document, not a plan.
1. What Is an Individual Development Plan?
An individual development plan is a written structure for developing a specific capability or area of experience. Its purpose is to move development from intention into something that can be worked on and checked: a named development area, a goal, the actions that address it, the support it depends on, and the evidence you will look at when you review it. The defining feature is the structure — an IDP is a document with fields, and filling them in is what forces the thinking.
What an IDP is not: it is not a performance review, not a job description, not a list of training courses, and not a commitment an employer makes to you. It is also not the same thing as a single development goal. A goal is one item; the plan is what surrounds it — the reasoning, the actions, the dependencies, the evidence and the record of what happened. Nor is it a training activity. Attending a workshop is an action that might sit inside a plan; it is not a plan in itself.
People write IDPs in different contexts. An employee-created IDP is written independently, kept privately, and may never be shown to anyone — useful when the direction you are interested in is not one your current employer has a stake in. A manager-supported IDP is drafted by the individual and then discussed with a manager, who may contribute opportunities, budget, time or a view on what the role is likely to require next. An organisation-supported IDP follows an employer’s own template and forms part of a development or review cycle, sometimes with an attached budget. All three are legitimate, and they produce genuinely different documents.
Use also varies between formal and informal. A formal IDP is filed, referenced in development conversations and sometimes tied to funding. An informal one might be a page in a notebook revisited every few months. The formality is not what makes it work; specificity and review are. Terminology varies too — some organisations call this a development plan, a growth plan or a learning plan, and some do not use any such document. There is no single standard behind the name.
One distinction is worth stating plainly. An individual development plan is not a performance improvement plan. A performance improvement plan is a performance-management process, initiated by an employer in response to concerns about performance, often with defined consequences. An IDP is a development tool and is not automatically a disciplinary or corrective process. Some organisations do use development documents inside performance processes, which is why the labels can blur; if you are asked to complete something and are unsure which it is, asking what it is for and how it will be used is a reasonable question. This guide is about development planning and is not legal or HR advice.
| Concept | What it means | Example |
|---|---|---|
| Individual development plan | A structured document connecting a development area to a goal, actions, support, evidence and a review point. | A written plan covering how you will develop the ability to run cross-functional projects. |
| Development goal | One specific capability or experience the plan is working toward. A plan can hold more than one, but each is narrower than the plan itself. | Be able to write and own the scope for a project involving three teams. |
| Development action | Something you actually do that is expected to close part of the gap. Actions are not the goal; they serve it. | Co-lead the next cross-functional project and write the scope document yourself. |
| Career goal | A broader direction or outcome over a longer horizon. Development goals may support it, but it usually depends on factors beyond your own development. | Move into project management within the next few years. |
| Performance objective | A target for the work of your current role, usually set with or by an employer and evaluated as part of performance management rather than development. | Deliver the quarterly campaign calendar on schedule. |
2. What Should an Individual Development Plan Include?
The elements below cover what a workable IDP can contain. There is no universally required format: organisations that run a formal process use different fields, and a plan you write for yourself can use whatever headings suit you. Not every IDP needs every element — plenty of effective plans use six or seven. Treat the table as a checklist of what a plan should be able to answer rather than a form to complete in full.
| IDP element | Purpose | Example |
|---|---|---|
| Current role / context | Anchors the plan in what you actually do, so the goal is realistic about the time and opportunities available. | Marketing specialist; most campaigns involve at least two other functions. |
| Current strengths | Records what you already demonstrate, which is often where the development opportunity comes from. | Campaign copy, channel reporting, reliable coordination with design. |
| Development area | Names the gap in plain language before any solution is chosen. | Has never set a campaign scope or agreed dependencies across teams. |
| Development goal | Converts the area into something specific enough to work on and recognise when reached. | Plan and run one cross-functional campaign end to end. |
| Why the goal matters | Keeps the plan honest. If the reason is thin, the plan usually stalls first. | The work already crosses functions; contributing pieces is no longer sufficient. |
| Actions | The work that closes the gap — usually real work, sometimes structured learning. | Co-own the next campaign; write the scope; chair the kickoff. |
| Resources | Tools, materials, budget or learning the actions depend on. | Existing campaign brief templates; a short planning course if a gap remains. |
| Support / people involved | Whose input or agreement the plan needs, where it needs any. | The current campaign owner as an informal mentor; manager's agreement on time. |
| Evidence of progress | What would show development happened, decided before you start rather than after. | A scope document used without rework; six status updates; written feedback. |
| Target / review point | When you will look at the plan again, tied to work where possible rather than an arbitrary date. | Campaign close, or three months if it runs longer. |
| Obstacles | What could realistically get in the way, named in advance so it is not a surprise. | Quarter-end workload; campaign may be delayed. |
| Dependencies | What the plan needs from other people or from circumstances outside your control. | Co-ownership requires the manager and current owner to agree. |
| Progress notes | A running record of what was done and what happened. This is what makes the review useful. | Chaired the kickoff; scope questioned on dependencies; revised before circulation. |
| Next action | The single next thing, so the plan is never ambiguous about what to do. | Draft the dependency list before Friday's planning meeting. |
| Revision trigger | What would make you change the plan rather than abandon it. | No suitable campaign within a quarter — switch to a smaller internal launch. |
If you strip it back to the minimum, three things do most of the work: the development area stated plainly, the actions that address it, and the evidence you will look for. Everything else exists to keep those three honest.
3. How to Create an Individual Development Plan
The sequence below works whether you are filling in an employer’s form or starting from a blank page. The order matters more than the format: naming the gap before choosing the solution is the step that separates a plan from a list of activities.
- 1. Clarify the purpose of the IDP. Decide what the plan is for before filling anything in. A plan written for yourself, a plan drafted to bring to a development conversation and a plan completed on an employer's form serve different purposes and end up looking different. If an employer has asked for one, it is reasonable to ask what they expect it to contain and how it will be used rather than guessing. If it is entirely your own, you can ignore any format including this one.
- 2. Document your current role and context. Write down what you are actually responsible for now, how your time is distributed and what is changing around the role. This is the part people skip, and skipping it produces plans that assume time and opportunities that do not exist. Context also dates the plan usefully: when you read it again in six months, knowing what the job looked like when you wrote it explains a lot.
- 3. Identify strengths. List what you already do well, with something concrete behind each item rather than an adjective. Strengths matter for two reasons. They are often the foundation of the development area — the next capability is frequently adjacent to an existing one. And a plan made only of deficits is demoralising to read, which is a practical problem, because a plan you avoid opening does nothing.
- 4. Identify development areas. Name the gap in plain language, before choosing any solution. Look at what you avoid, what takes disproportionate effort, what you escalate, what the role is drifting toward and what recurs in feedback. Write it as a description of a situation rather than a label: “loses the thread when presenting to more than a dozen people” is workable; “poor communicator” is not.
- 5. Choose a development goal. Pick one area, occasionally two, and convert it into something specific. A goal should be narrow enough that you could describe what doing it looks like. Choosing one area is not a rule, but plans with five parallel goals tend to progress on none of them, because development runs on real opportunities and there are rarely five available at once.
- 6. Select development actions. Choose actions that address the gap you named rather than actions that are easy to arrange. Most development happens through work: taking on something you have not done, doing it with review, doing it again without. Courses, reading and formal learning have a place, particularly for defined knowledge gaps and for anything with a required credential, but a course is rarely sufficient on its own for a capability gap.
- 7. Identify resources and support. Note what the plan depends on: time, access, budget, a mentor, an opportunity that someone else controls. Doing this early surfaces the dependency while there is still time to arrange it, and it makes any conversation with a manager concrete — a request for a specific opportunity is easier to respond to than a general statement about wanting to grow.
- 8. Define evidence of progress. Decide now what would indicate that development has happened. Evidence is usually things produced, things done, or specific feedback received — not a feeling of improvement and not an invented metric. Defining it in advance also stops the plan from being retroactively marked complete because the time elapsed.
- 9. Set a review point and revise when needed. Choose when you will look at the plan again, tied to the work where possible: at project close, after three presentations, at the next development conversation. At the review, the question is not only whether you did the actions but whether the goal still makes sense. Revising a plan on better information is the plan working, not the plan failing.
4. Identify Your Strengths and Development Areas
This step is where IDPs most often go wrong, because it gets treated as a list of weaknesses. It is not. The useful version records what you already demonstrate alongside what you want to develop, for a practical reason: development areas are usually adjacent to existing strengths, and knowing what you are building from tells you which actions have a chance of working.
Look across several sources rather than relying on one. What you handle comfortably and what you avoid, the responsibilities you already own well, the areas where you need more experience rather than more knowledge, the difficulties that recur, the responsibilities the role is moving toward, feedback from a manager where it is specific, feedback from peers and stakeholders who rely on your work, how projects actually went, how the job requirements have shifted, the direction you are interested in, and — where relevant — what you are simply interested in developing.
| Evidence / source | Question to ask | Possible insight |
|---|---|---|
| Work you handle comfortably | What do I get asked to do because people expect it to go well? | A demonstrated strength worth recording, and often the base the next capability builds on. |
| Work you avoid or postpone | What do I keep pushing to the end of the week? | Sometimes a development area, sometimes a preference. Worth separating the two. |
| Recurring difficulties | What goes wrong in a similar way more than once? | A pattern is more informative than a single bad instance. |
| Responsibilities you are moving toward | What does the work I am being pulled into require that I have not done? | A development area defined by direction rather than deficiency. |
| Manager feedback | What has been raised more than once, and what was the specific example? | Useful where it is specific. Feedback is information to evaluate, not automatically an objective account. |
| Peer or stakeholder feedback | What do people who rely on my work ask for repeatedly? | Often surfaces friction a manager never sees. Treat it the same way: evidence, weighed alongside the rest. |
| Project outcomes | Where did a piece of work go less smoothly than expected, and which part? | Locates the gap in a stage of the work rather than in a personal trait. |
| Changing job requirements | What does my role require now that it did not two years ago? | A development area created by the role moving rather than by any shortfall. |
| Desired career direction | What does the direction I am interested in commonly require? | Connects the IDP to a longer-range goal without collapsing the two. |
| Personal interest | What would I develop even if no one asked me to? | Not every development area has to be a deficit. Interest sustains plans that obligation does not. |
Feedback deserves a note of its own. It is information to evaluate, not automatically an objective account of your work. People give feedback from a partial view, in a specific context, sometimes about a single incident. The useful question is whether the same thing comes up from more than one source, with concrete examples attached. A single comment is a data point; a pattern is worth planning against. Equally, none of this requires constant self-monitoring. A periodic look at these questions is enough; turning your own working life into a tracking exercise is its own problem.
Example: turning a strength into a development area
A fictional example of how the two connect. The strength is strong written communication — documentation and updates that other people reuse. The development area is presenting complex information verbally to larger groups, which is the same underlying skill in a setting where the structure keeps collapsing. The goal is more confidence and clarity in structured presentations. The actions are preparing and delivering presentations that are already part of the work, observing experienced presenters, requesting targeted feedback, reviewing what was clear and what was not, and adjusting the next one. The evidence is the presentations delivered, the specific feedback received, a clearer structure that can be described and repeated, and being able to answer relevant questions without losing the thread. No percentages, no scores: there is no honest way to quantify this, and inventing a number would only make the plan look rigorous.
IDP entry — strength to development area Strength: Strong written communication. Written updates and documentation are regularly reused by others. Development area: Presenting complex information verbally to larger groups. Comfortable one to one; loses structure in front of fifteen people. Goal: Develop more confidence and clarity when delivering structured presentations to a mixed audience. Actions: - Prepare and deliver presentations that are already part of the work rather than inventing occasions. - Observe two experienced presenters and note how they open, sequence and handle questions. - Request targeted feedback afterwards on one thing: whether the main point landed. - Review what was clear and what was confusing while it is still fresh. - Adjust the structure of the next presentation based on that review. Evidence of progress: - Presentations actually delivered, with the audience noted. - Specific feedback received, not general reassurance. - A clearer structure that I can describe and repeat. - Being able to answer relevant questions without losing the thread. Review: After three presentations, check whether the difficulty is preparation, structure or the live delivery — the fix is different for each.
5. Set Individual Development Goals
A development area is not a goal. The area is where the gap is; the goal states what being further along would look like. Take project leadership as the area. “Become a better leader” restates the area with an adjective attached, and cannot be acted on or reviewed. “Develop experience coordinating a cross-functional project by planning milestones, communicating dependencies and documenting lessons from the project” names work you could start, and produces something observable as a by-product.
Two cautions. Do not attach invented numbers to make a goal look measurable — “improve presentation effectiveness by 30%” measures nothing, because the figure has no source. And not every goal needs a strict deadline. Development that depends on a real opportunity arriving is better tied to that opportunity (“at the close of the next cross-functional project”) than to a date chosen because the form has a date field.
| Area | Weak goal | Stronger goal |
|---|---|---|
| Communication | “Communicate better.” | Be able to open a written update with the decision and its consequence, so that recipients outside the team can act on it without follow-up questions. |
| Analytical skills | “Get better with data.” | Be able to source, build and explain the monthly analysis currently produced by a colleague, including what changed and why. |
| Project management | “Become a better leader.” (for a project-leadership gap) | Develop experience coordinating a cross-functional project by planning milestones, communicating dependencies and documenting lessons from the project. |
| Technical capability | “Learn [tool].” | Be able to complete the recurring task that currently requires [tool] expertise without support, including the part that usually goes wrong. |
| Leadership | “Develop leadership skills.” | Be able to set the direction for a defined piece of work, delegate two substantial parts of it and hold the coordination without doing the delivery myself. |
| Stakeholder management | “Work better with other teams.” | Be able to run a discussion where two teams want different things and reach a documented decision, including what was traded away. |
| Industry knowledge | “Stay current.” | Be able to explain how [specific regulation or change] affects our work and what it implies for the decisions my team makes. |
| Career transition | “Move into [field].” | Close the one requirement that appears in almost every posting for [target occupation] and produce one piece of work in that area that someone in the field could review. |
6. Turn IDP Goals Into Actions
Actions should match the actual gap. A knowledge gap can genuinely be closed by reading, a course or formal study. An experience gap cannot — it closes by doing the work, usually with review, and then doing it again. Most plans that stall have chosen the wrong category: a course booked for a problem that was never about knowledge.
The range of actions worth considering is wider than most plans use: stretch assignments, owning a project, shadowing someone in an adjacent function, mentoring or being mentored, coaching, asking for targeted feedback, courses and workshops, formal education where it is genuinely relevant, required licences or certifications where the occupation demands them, presenting, cross-functional assignments, deliberate practice, reading and research, professional communities, and portfolio work where the field supports it.
| Development goal | Possible action | Evidence |
|---|---|---|
| Coordinate a cross-functional project | Stretch assignment: co-lead a real project with an experienced owner. | The scope document, the dependency list, the close-out summary. |
| Present clearly to larger groups | Deliver presentations already part of the work; observe experienced presenters; request targeted feedback. | Presentations delivered, the feedback received, a structure you can repeat. |
| Learn a defined technical skill | Targeted course or workshop, followed immediately by applying it to real work. | The completed work, not the certificate. A course with no application leaves nothing to point at. |
| Understand an adjacent function | Shadowing, or a cross-functional assignment with a defined deliverable. | Notes on how the function works; a deliverable produced jointly. |
| Develop coaching ability | Mentor one colleague or onboard a new joiner, with agreed check-ins. | Feedback from the person; what they can now do independently. |
| Build judgement in a domain | Reading and research, discussion with experienced practitioners, then a decision made and documented. | The written rationale and the alternatives considered. |
| Meet a licensing or credential requirement | The required licence, certification or formal education for that occupation. This is a genuine requirement, not a development preference. | The credential itself, since in these cases the credential is the requirement. |
| Build reviewable work in a new area | Portfolio work, a side project, or relevant volunteering where the field supports it. | The work itself, in a form someone in the field can look at. |
| Deepen professional network and context | Professional communities, industry groups, conversations with people doing the target work. | Notes from specific conversations; a clearer, better-informed target. |
Courses and certifications are not universally necessary. In some occupations a specific licence or credential is a hard requirement, and in those cases it belongs in the plan as a requirement rather than a development choice. Elsewhere, optional certificates are one option among many and they do not substitute for a required credential where one exists. If you are unsure which category something falls into, the requirements listed in real job postings for the work are a better guide than a course provider’s description of its own programme.
7. Individual Development Plan Examples
Six further examples, each in a different area and none of them repeating the marketing scenario at the top of the page. They are written to be adapted rather than copied; the bracketed parts are yours to replace. None of them is a recommended development direction — what is worth developing depends entirely on your role and where you are heading.
Example 1 — Communication
Current strengths: Clear written work that others reuse; strong one-to-one discussion. Development area: Communicating decisions and trade-offs to audiences outside the team who do not share the background. Goal: Explain the decision, the reason and the trade-off in a form a non-specialist audience can act on. Actions: Own the recurring external update; restructure it to lead with the decision; ask a recipient outside the team for feedback after each of the first three; revise the format at least twice. Resources/support: The existing update template; one colleague outside the team willing to comment. Evidence: Updates sent under your name; fewer repeat clarification questions; the format adopted by someone else. Review approach: After one quarter of updates; if the same questions persist, the issue is content selection rather than structure.
INDIVIDUAL DEVELOPMENT PLAN — communication Current role: [role] Current strengths: Written work is clear and reused by others; strong one-to-one discussion; comfortable with the subject matter. Development area: Communicating decisions and trade-offs to audiences outside my own team, who do not share the background. Development goal: Be able to explain the decision, the reason and the trade-off in a form a non-specialist audience can act on. Why this matters: Decisions I contribute to are increasingly reviewed by people outside the team, and the current updates generate repeated clarification questions. Actions: - Take ownership of the recurring update sent outside the team. - Restructure it to lead with the decision and its consequence rather than the process. - Ask one recipient outside the team for feedback after each of the first three updates. - Revise the format at least twice based on what was still unclear. Resources/support: The existing update template; one colleague outside the team willing to give feedback; recordings or notes from updates that worked well. Evidence of progress: Updates sent under my name; fewer clarification questions on the same points; the revised format adopted by someone else; specific feedback on clarity. Target/review point: After one full quarter of updates. Obstacles or dependencies: Ownership of the update has to be handed over; feedback depends on someone else's time. Progress notes: Next action: What would make me revise the plan: If clarification questions persist after two format revisions, the issue is probably content selection rather than structure — change the goal accordingly.
Example 2 — Data and analytical skills
Current strengths: Comfortable with the reporting tools in daily use; good understanding of what the business actually asks of the numbers. Development area: Producing the monthly analysis currently handled by a colleague, including sourcing the data. Goal: Source, build and explain the analysis independently, including what changed and why. Actions: Pair on the next two cycles; take the third yourself with review; close a specific tooling gap with a targeted course only if pairing has not resolved it. Resources/support: The colleague currently producing it; access to the source data; the existing query library. Evidence: Two cycles produced independently; the written commentary; the colleague no longer in the workflow. Review approach: After the third cycle, check whether errors cluster in one stage — sourcing, building or explaining.
Example 3 — Project management
Current strengths: Reliable execution against someone else's plan; good relationships with the teams involved. Development area: Scoping and planning rather than delivering to a plan already written. Goal: Write and own the scope, dependency list and schedule for one real project. Actions: Draft the scope for [project] and have it reviewed before circulation; record estimates against actuals; run the close-out summary. Resources/support: An experienced project owner to review the scope; the team's existing templates. Evidence: Scope document used without major rework; the estimate-versus-actual record; a close-out summary. Review approach: At project close, comparing where the plan diverged from reality and why.
Example 4 — Technical skills
Current strengths: Strong grasp of the domain the tooling serves; able to specify what the output needs to be. Development area: Doing the [specific technical task] currently escalated to another team. Goal: Complete the task end to end without escalation, including the part that usually goes wrong. Actions: Work through the task with the other team twice; document the steps as you go; take the next request yourself with their review; use a targeted course only for the specific concept that is still unclear. Resources/support: The team that currently handles it; access and permissions; a sandbox to make mistakes in. Evidence: Requests handled independently; the written procedure; the escalation count over a period. Review approach: After three independent attempts; if failures recur at the same step, narrow the goal to that step.
Example 5 — Career progression
Current strengths: Consistent delivery on your own scope; trusted with the team's most technical work. Development area: Performing parts of the wider role you are working toward, particularly owning a decision rather than recommending one. Goal: Hold one responsibility from the wider scope, make and document a decision within it, and present the outcome. Actions: Map the target responsibilities; agree one to take on; own a decision end to end with a written rationale; present it to the group affected. Resources/support: Manager's agreement on scope; one person already at that level to sanity-check the reasoning. Evidence: The responsibility held; the written rationale; feedback from an affected team. Review approach: At the next development conversation. This builds readiness; it does not make a promotion happen.
INDIVIDUAL DEVELOPMENT PLAN — career progression Current role: [role] Current strengths: Consistent delivery on my own scope; trusted with the team's most technical work; good working relationships across two adjacent teams. Development area: Performing parts of the wider role I am working toward, particularly owning a decision end to end rather than recommending one. Development goal: Hold one responsibility from the wider scope, make and document a decision within it, and present the outcome to the people affected. Why this matters: My current evidence is all execution. A case for wider scope needs evidence of judgement, not only output. This plan builds readiness; it does not make a promotion happen, which depends on openings and decisions I do not control. Actions: - Map the responsibilities of the wider scope against what I currently do. - Agree with my manager on one responsibility I can take on now. - Own one decision within it, including the written rationale and the alternatives rejected. - Present the outcome to the affected group and collect their reaction. Resources/support: Manager's agreement on scope; access to whatever information the decision requires; one person already at that level to sanity-check the rationale. Evidence of progress: The responsibility held over a defined period; the written rationale; feedback from an affected team; a record of what changed as a result. Target/review point: The next scheduled development conversation. Obstacles or dependencies: Requires the responsibility to be available; organisational changes may reassign it. Progress notes: Next action: What would make me revise the plan: If no responsibility from the wider scope becomes available, shift the goal to depth in the current one rather than waiting.
Example 6 — Career change
Current strengths: Substantial transferable experience, often described differently in the target field. Development area: Meeting the recurring requirements of [target occupation] that your current work does not cover. Goal: Close the one requirement that appears in almost every posting, and produce one piece of work someone in the field could review. Actions: Collect real postings and list requirements by frequency; mark what you already meet through transferable work; choose one genuine gap; complete one piece of real or volunteer work in that area; speak with two people doing the work. Resources/support: People already in the target occupation; any required credential body; time to produce the work. Evidence: The requirements list; the completed piece of work; notes from those conversations. Review approach: After the conversations — check whether the direction still makes sense before investing further.
8. Individual Development Plan Examples for Leadership
Leadership development does not necessarily mean becoming a people manager. Treating the two as the same thing narrows the plan unnecessarily and sends people toward a role they may not want. Several distinct paths are worth separating: project leadership, where you hold responsibility for an outcome and for coordination without managing anyone; people management, where the responsibility is for individuals, their development and their workload; specialist or technical leadership, where depth of judgement in a domain is what others rely on; mentoring, where the contribution is developing other people without authority over them; cross-functional leadership, holding work together across organisational boundaries; and strategic influence, shaping what gets done rather than how it gets done.
These call for different plans, and choosing the wrong one is a common and expensive mistake. None of them guarantees a promotion — developing leadership capability can make a case possible, but whether a role exists and who is chosen for it is decided elsewhere.
Leadership example 1 — Delegation
Current strengths: High personal delivery; deep knowledge of how the work is done. Development area: Handing over substantial work rather than absorbing it, which currently caps what anyone else can develop. Goal: Hand over a significant piece of work with enough context that it can be done well without you, and support it without taking it back. Actions: List what you hold and mark what genuinely only you can do; hand over two items with context, constraints and decision rights stated; agree check-in points in advance. Resources/support: A peer willing to challenge your list; agreement on which risks can be distributed. Evidence: Two pieces of work held by others through a full cycle; a record of interventions outside the agreed check-ins. Review approach: After both have run one cycle; note what you did with the freed capacity.
Leadership example 2 — Decision-making
Current strengths: Thorough analysis; rarely wrong when you do decide. Development area: Deciding with incomplete information, and at the point where a decision is still useful. Goal: Make and document decisions in your area of responsibility at the moment they are needed, including the alternatives rejected. Actions: Keep a decision log with the reasoning and what was unknown at the time; set a point at which you decide with whatever is available; review three decisions afterwards against what was actually knowable. Resources/support: Someone experienced to review the log; clarity on which decisions are actually yours to make. Evidence: The decision log; decisions made at the point of need rather than after; what the review of three of them showed. Review approach: After three logged decisions; look at whether delay improved the outcome or only the comfort.
Leadership example 3 — Stakeholder communication
Current strengths: Credible with your own team; strong grasp of the detail. Development area: Communicating with audiences who have different priorities and no shared context. Goal: Run a discussion where two groups want different things and reach a documented decision, including what was traded away. Actions: Prepare the trade-offs before the meeting rather than during it; chair one discussion with genuine disagreement; document the decision and the dissent; follow up with both groups. Resources/support: An observer who will tell you honestly how it went; the existing decision-log format. Evidence: The documented decision with dissent recorded; feedback from both groups; whether the decision held. Review approach: After two such discussions; examine what you avoided as much as what you handled.
Leadership example 4 — Coaching and mentoring
Current strengths: People ask you how to do things; patient with questions. Development area: Developing someone's capability rather than answering their immediate question. Goal: Support one person over a period so that they can do independently something they currently escalate to you. Actions: Agree the aim with them; work through it together once; step back and review their attempt; ask what was missing from your explanation. Resources/support: Their agreement and interest; time in the schedule rather than in the gaps. Evidence: What they can now do unaided; their feedback on what helped; the change in escalations. Review approach: After the handover period; distinguish between teaching the task and building their judgement.
Leadership example 5 — Project ownership and conflict
Current strengths: Trusted to deliver; good working relationships across teams. Development area: Holding a project together when teams disagree about scope, instead of routing the disagreement upward. Goal: Own one cross-team project through a real scope disagreement to a documented resolution. Actions: Take the scope and dependency list yourself; surface the disagreement early rather than at the deadline; document what was agreed and what was dropped; run the close-out. Resources/support: An experienced lead to review the scope; sponsor clarity on what is negotiable. Evidence: The scope used without rework; the resolution documented; feedback from a participant and a stakeholder. Review approach: At project close, or four months in if it runs longer.
INDIVIDUAL DEVELOPMENT PLAN — leadership (project leadership) Name: [name] Current role: Senior analyst, [team] Date created: [date] Review date: [date] Current strengths: - Deep knowledge of the reporting the business relies on. - Trusted to handle the work others escalate. - Good relationships with the two teams I work alongside most. Development area: Leading a piece of work through other people. I lead by doing the work myself, which does not scale and does not develop anyone else. Leadership here means project leadership — I am not seeking a people-management role. Development goal: Be able to take a defined project, set its direction, distribute the work, keep it coordinated across teams, and bring it to a documented close without doing the majority of the delivery myself. Why this matters: The projects I am pulled into now span three teams. Someone has to hold the shape of them, and the alternative to developing this is that I keep absorbing the coordination informally without the authority or the credit. Actions: - Ask to lead the next project that involves more than one team. - Write the scope, the dependency list and the decision log myself. - Delegate at least two substantial pieces of delivery and resist reclaiming them. - Chair the recurring coordination meeting, including the one where there is genuine disagreement. - Ask one participant and one stakeholder for feedback on how the project was run, not on its outcome. Resources/support: - An experienced project lead willing to review the scope before it circulates. - Manager's agreement to protect the time. - The team's existing project and decision-log templates. Evidence of progress: - A scope and dependency list used without major rework. - Two pieces of delivery genuinely held by other people. - A decision log showing decisions made, including ones where there was dissent. - Feedback from a participant and a stakeholder about how the work was run. - A close-out summary with what I would do differently. Target/review point: Project close, or four months from the start date if it runs longer. Potential obstacles or dependencies: Project availability; the willingness of others to take delegated work; my own tendency to take work back when a deadline gets close. Progress notes: Next action: What would make me revise the plan: If delegation is the part that keeps failing rather than the coordination, narrow the goal to delegation specifically and plan against that instead.
9. Individual Development Plan Examples for Managers
These are IDPs for someone who is already a manager — their own development, not a process for writing plans on behalf of their team. Management is a set of practices that can be developed like any other, and the same structure applies: name the area, state the goal, choose actions, decide what evidence would show something changed.
One caveat before the examples. There is no single correct management style, and nothing below should be read as the right way to manage — what works depends on the team, the work and the organisation. These plans are also about the manager’s own practice, not about assessing or diagnosing anyone who reports to them, and they are not HR or legal guidance. Nor can a development plan promise that team performance will improve; it can change what the manager does, which is the part within their control.
Manager example 1 — Delegation
Current strengths: Steady team delivery; comfortable with the operational detail. Development area: Retaining the hardest and most visible work, which caps what the team gets to develop. Goal: Hand over two significant pieces of work with full context and support them without reclaiming them. Actions: List what you hold and why; choose two items where the reason is habit; hand over with constraints and decision rights stated; agree check-ins in advance. Resources/support: A peer manager to review the list; your own manager's view on acceptable risk. Evidence: Two items held by others through a cycle; handover notes the person found sufficient; interventions counted. Review approach: After both cycles complete.
INDIVIDUAL DEVELOPMENT PLAN — for a current manager Name: [name] Current role: Team manager, six direct reports Date created: [date] Review date: [date] Current strengths: - The team's delivery is steady and commitments are met. - Individual relationships are good; people raise problems early. - Comfortable with the operational detail of the work. Development area: Delegation. I retain the work that is hardest or most visible, which caps what the team is given the chance to develop and concentrates risk on me. Development goal: Be able to hand over a significant piece of work with enough context that it can be done well without me, and support it without taking it back. Why this matters: Two people on the team have asked for wider scope, and I currently cannot offer it without giving up work I have been holding. This is about my own practice as a manager; it is not a plan for anyone else and not an assessment of anyone's performance. Actions: - List everything I currently hold and mark what only I can do and why. - Choose two items where the reason is habit rather than necessity. - Hand each over with the context, the constraints and the decision rights stated explicitly. - Agree check-in points in advance instead of intervening ad hoc. - Ask the two people afterwards what was missing from the handover. Resources/support: - A peer manager to review what I claim only I can do. - My own manager's view on which risks are acceptable to distribute. - Time in one-to-ones for the handover conversations rather than squeezing them in. Evidence of progress: - Two pieces of work held by other people through a full cycle. - Handover notes that the person says were sufficient. - A record of how many times I intervened outside the agreed check-ins. - What I did with the time that freed up. Target/review point: After both handovers have run one full cycle. Potential obstacles or dependencies: Workload peaks make handing over feel risky; one item depends on access that has to be granted first. Progress notes: Next action: What would make me revise the plan: If the handovers succeed easily, the real development area is probably what I do with the freed capacity — revise the plan toward that rather than delegating more for its own sake.
Manager example 2 — Coaching
Current strengths: Approachable; people bring problems early. Development area: Solving problems for people rather than developing how they approach them. Goal: Respond to recurring questions in a way that builds the other person's capability to answer them. Actions: Notice when you are about to answer and ask instead what they would do; agree with two people what they want to develop; review their attempts rather than pre-empting them. Resources/support: Time in one-to-ones; their interest in developing the specific area. Evidence: Questions that stop recurring; what those two people can now handle unaided; their own account of what helped. Review approach: After a quarter; check whether escalations moved or simply went elsewhere.
Manager example 3 — Feedback
Current strengths: Honest in one-to-ones; good at recognising strong work. Development area: Giving specific, timely feedback when something has not gone well, rather than deferring it. Goal: Give feedback close to the event, with a concrete example and a clear request, rather than saving it. Actions: Prepare the example and the request before the conversation; give the feedback within a week of the event; ask afterwards whether it was clear and usable. Resources/support: A peer to rehearse difficult framings with; clarity on what is a development conversation and what belongs in a formal process. Evidence: Feedback given close to events; the person's account of whether it was actionable; what changed afterwards. Review approach: Quarterly, or after any conversation that went badly.
Manager example 4 — Prioritisation
Current strengths: Responsive to requests; team rarely says no. Development area: Deciding what the team will not do, and defending it. Goal: Maintain an explicit list of what the team is not doing and be able to explain the trade-off to the requester. Actions: Make the current commitments visible; respond to new requests with the trade-off rather than absorbing them; review at the end of each cycle what was dropped and whether it mattered. Resources/support: Your own manager's backing on trade-offs; a shared view of the team's commitments. Evidence: The explicit not-doing list; requests declined with a stated reason; whether the team's committed work finished. Review approach: At the end of two planning cycles.
Manager example 5 — Cross-functional coordination
Current strengths: Strong within your own function; the team's internal work runs smoothly. Development area: Working across functions where priorities conflict and no one has authority over the others. Goal: Establish a working arrangement with one adjacent function that survives a genuine conflict of priorities. Actions: Meet the counterpart outside a crisis; agree how conflicts will be raised and decided; document the arrangement; test it on a real disagreement and review it afterwards. Resources/support: The counterpart's willingness; sponsor clarity on escalation. Evidence: The documented arrangement; how one real conflict was handled; both teams' view afterwards. Review approach: After the first real test.
10. Individual Development Plan for Employees
From an employee’s side, there are two routes into an IDP, and they are not mutually exclusive. You can write one independently: it costs nothing, needs no approval and can point somewhere your employer has no particular interest in. Or you can develop one with manager input, which is worth doing when the plan depends on something they control — an assignment, time, budget, access to a project.
If a development conversation is coming, drafting the plan beforehand changes the conversation entirely. Arriving with a named development area, a proposed goal and one specific request is a different discussion from arriving with a general wish to grow. It also makes the request easy to respond to: “I would like to co-own the next cross-functional project” can be answered; “I want more responsibility” usually cannot. Decide in advance what support you are actually asking for, and what you will do if the answer is no — a plan with an alternative path is more robust than one that depends on a single approval.
The most useful discipline here is separating what you control from what your employer does. Development actions are yours. Employment outcomes are not, and a plan built around them has no way to make progress.
| Goal or outcome | How much control do I have? | Better planning focus |
|---|---|---|
| Completing a relevant project | Largely within your control once the assignment exists. | Put it in the plan as an action with a defined output. |
| Practising a specific skill | Within your control. | Plan the occasions to practise, not just the intention. |
| Requesting feedback | Within your control to ask; the response is not. | Plan the request and the question; treat the answer as information. |
| Building evidence of capability | Largely within your control. | Decide what the evidence is before you start. |
| Completing required learning | Within your control, subject to cost and time. | Note the dependency if funding or time has to be approved. |
| Being given a stretch assignment | Partly — you can ask; someone else decides. | Plan the request, and plan an alternative if it is declined. |
| Receiving a promotion | Not within your control. | Plan the readiness and the evidence; treat the outcome as separate. |
| Receiving a raise | Not within your control. | Keep it out of the IDP goals; handle pay as its own conversation. |
| Being selected for a specific role | Not within your control. | Develop the capability the role requires; the selection is a separate event. |
| Organisational restructuring | Not within your control. | Note it as a dependency and a possible revision trigger. |
None of this is absolute. Circumstances vary, and in some organisations an employee has considerably more influence over assignments than in others. The point is not that outcomes are impossible to influence, but that they do not belong in the goal line of a plan, because you cannot act on them directly.
11. Individual Development Plan vs. Professional Development Plan
These two terms overlap substantially, and some organisations use them interchangeably. There is no universally accepted distinction, and anyone who tells you there is a firm rule is describing their own employer’s convention rather than a standard.
The tendency, where a difference exists, is this: an individual development plan is often a more structured document with defined fields, centred on one person’s strengths, development areas, goals, actions, support and evidence, and designed to be revisited and annotated. A professional development plan is often used as a broader term for development planning generally, sometimes with a wider view of career direction and usually with a freer structure. Both are planning tools; both can hold the same content. If an employer asks you for one, asking what they expect it to contain is more reliable than assuming.
| Dimension | Individual development plan | Professional development plan |
|---|---|---|
| Typical emphasis | Often framed around one person's development record: their strengths, gaps, actions and evidence, in a document that gets revisited. | Often framed around professional growth more broadly, including direction, skills and career progression. |
| Format | Frequently a structured form with defined fields, sometimes provided by an employer. | Frequently freer in structure, shaped by whoever writes it. |
| Goals | Usually development goals expressed as capabilities or experience. | May combine development goals with broader professional or career direction. |
| Actions | Usually tied field by field to the development area they address. | Usually tied to goals, with similar logic and less prescribed structure. |
| Support | Often includes an explicit field for support, resources or people involved. | Support may be included but is less often a fixed field. |
| Review | Often includes named review points and progress notes as part of the document. | Review is recommended in most formats but less often built into the form. |
| Organisational terminology | Common in organisations that run a formal development process, and in some public-sector settings. | Common as a general term across many contexts, including self-directed planning. |
If the broader version is what you need — development planning across skills, direction and career progression rather than a single structured document — our guide to the professional development plan covers that format, with its own template and examples.
12. Individual Development Plan and Career Goals
A career goal is a direction or an outcome: where you want the work to go over a longer horizon. An IDP is the development work that may help you move toward it. The two are often confused, which produces plans made of outcomes rather than actions — and an outcome cannot be worked on directly.
Take a career goal of moving toward project management. The IDP underneath it would hold development goals such as building project-planning experience, practising stakeholder communication, gaining experience tracking dependencies across teams, and producing documented project outcomes that someone could look at. Each of those is work you can start. Whether the transition happens depends on openings, timing and decisions made by other people, and nothing in the plan changes that.
If the direction itself is what is unclear, that is a different task from development planning: our guide to career goals covers turning broad ambitions into something specific enough to plan around. If the direction involves a different occupation altogether, the sequence is different again — see how to change careers for evaluating and preparing a transition. Where the development area is a skill you also want to be able to describe on paper, our guide to skills for a resume covers that side of it. And if the direction is wider responsibility in your current organisation, the mechanics of that sit in how to get a promotion and how to ask for a promotion. This guide stays on the development side of all of those.
13. Individual Development Plan and Salary Growth
An IDP may help you develop relevant capability. It does not determine compensation. Someone can complete a plan in full, build genuine evidence, and see no change in what they earn, because pay is set by employers within markets and depends on factors the plan does not touch.
Where wage research is useful is as context. If a development plan relates to taking on broader responsibilities, to a target occupation you are working toward, to preparing for a promotion or to a career transition, it helps to know what the wage data reports for those occupations and locations before deciding how much to invest in the plan and what to do afterwards. That is a separate exercise from the plan itself, and it belongs after the development thinking rather than instead of it.
Look up wages for an occupation
Search an occupation and a location to see the reported wage data. Running it for your current occupation and again for one your IDP is working toward makes the comparison concrete.
What wage data can and cannot tell you
BLS occupational wage data describes wages across workers in an occupation. It does not determine what a particular person should earn, what an employer will offer or whether completing an individual development plan will result in higher pay.
Wage percentiles are not experience levels. A higher percentile reflects higher reported pay within the occupation, which can be driven by industry, employer size, region, shift patterns or specialisation in combinations the data does not separate out. Nothing here predicts an individual’s salary, guarantees a raise, or calculates taxes or take-home pay.
You can browse pay by occupation and state from the FindMySalary homepage or explore salaries by occupation. If you reach the point where a pay conversation is the right next step, our guides on how to ask for a raise and how to negotiate salary cover that separately.
14. How to Track and Review an IDP
The progress notes are what separate a plan that develops someone from a document that was filled in once. They do not need to be elaborate — a few lines after anything relevant happens is enough — but they need to exist, because at review time you are otherwise reconstructing several months from memory, and memory reliably favours the version where things went well.
Worth recording as you go: actions completed, experience actually gained, the work or practice where the skill was applied, the evidence produced, feedback received, obstacles that appeared, dependencies that did or did not come through, priorities that changed, new development needs that surfaced, the next action, and any revisions you made to the plan along the way.
IDP review questions
- 1. What actions did I complete?
- 2. What did I actually practise or apply, as opposed to plan?
- 3. What evidence of progress exists that someone else could look at?
- 4. What remains difficult, and is it the same difficulty as before?
- 5. What feedback did I receive, and how specific was it?
- 6. What did I learn that I did not expect when I wrote the plan?
- 7. Have my responsibilities or priorities changed since then?
- 8. Is the development goal still relevant to where I am now?
- 9. What should I do next, concretely?
- 10. What should I revise in the IDP — continue, stop, add or change?
There is no universal review frequency, and anyone prescribing one is guessing at your circumstances. Tying the review to the work usually beats a calendar interval: at project close, after three attempts at the thing being practised, at the next development conversation. Where an employer runs a formal cycle, that cycle tends to set the rhythm whether or not it is the ideal one.
An IDP can be revised, and revising it is normal. Roles change, priorities move, opportunities fail to appear, and the development area sometimes turns out to be a different one than you thought. Changing the plan on better information is the plan working. The only version that fails quietly is the one that is never opened again.
15. Individual Development Plan Mistakes to Avoid
None of these is fatal, and most plans contain one or two. They are worth knowing mainly so that when a plan stops moving, you can find the reason quickly.
- 1. Treating the IDP as paperwork. A plan completed to satisfy a form gets filed and never opened. If it is required, it can still be written so that it is useful to you.
- 2. Listing only weaknesses. A plan made entirely of deficits misses that the next capability usually builds on an existing strength, and it is harder to return to.
- 3. Vague development goals. “Improve leadership” cannot be acted on or reviewed. A goal should describe something you could start this month.
- 4. Setting too many goals. Development runs on real opportunities, and several rarely appear at once. Plans with many parallel goals tend to progress on none.
- 5. Choosing activities before identifying the gap. Picking the course first and naming the gap afterwards produces activity that does not address anything in particular.
- 6. Collecting certificates without a purpose. Credentials are useful where they are required or where they close a defined knowledge gap. Accumulating them otherwise is expensive and shows little.
- 7. No applied practice. Capability is usually built by doing the work with review, then doing it again. Learning without application rarely transfers.
- 8. No evidence of progress. Without evidence decided in advance, the review becomes a matter of impression, and the plan quietly gets marked done.
- 9. Relying entirely on manager direction. A manager can contribute opportunities and perspective. Waiting for someone else to define your development usually means waiting.
- 10. Ignoring resources and dependencies. A plan that silently depends on time, budget or an opportunity someone else controls stalls without anyone noticing why.
- 11. Confusing employer-controlled outcomes with development actions. “Get promoted” is not a development action. The actions are what you do; the outcome is decided elsewhere.
- 12. Never recording progress. Progress notes are what make a review worth doing. Without them you are reconstructing several months from memory.
- 13. Never reviewing the plan. An unreviewed plan gradually describes a job you no longer have. Review is what keeps it attached to reality.
- 14. Assuming the IDP guarantees promotion or pay. It is a planning tool. It can build capability and evidence; it does not determine what an employer decides or offers.
Individual Development Plan Template: Detailed Version
A longer version with numbered prompts, for when you want the document to carry more of the thinking. It is plain text with nothing to download — copy it, delete the prompts you do not need, and keep it somewhere you will actually open again.
INDIVIDUAL DEVELOPMENT PLAN Name: Current role: Date created: Review date: 1. Current context What are my current responsibilities and circumstances? 2. Current strengths What capabilities or experience do I already demonstrate? 3. Development area What do I want or need to develop? 4. Development goal What capability or experience am I working toward? 5. Why this matters How does this connect to my work or broader career direction? 6. Actions What will I do to develop this capability? 7. Resources What tools, learning or opportunities may help? 8. Support Whose input, feedback or support may be useful? 9. Evidence of progress What would show that meaningful development has occurred? 10. Obstacles and dependencies What could affect the plan? 11. Progress notes What happened when I applied the development actions? 12. Next action What will I do next? 13. Review What has changed since the plan was created? 14. Revision What should I continue, stop, add or change?
Frequently Asked Questions
What is an individual development plan?
An individual development plan, often shortened to IDP, is a structured document for identifying development goals, the actions that can support those goals and the evidence you will use to evaluate progress. Depending on the organisation and the situation, it may be created by an employee independently or developed with input from a manager, mentor or another relevant person.
What does IDP stand for?
IDP stands for individual development plan. The abbreviation is common in organisations that run a formal development process, though not every employer uses either the term or the format.
What should be included in an individual development plan?
Most useful plans cover the current role and context, current strengths, a development area, a development goal, why it matters, actions, resources and support, evidence of progress, a review point, obstacles and dependencies, progress notes and a next action. There is no universally required set of fields, and plenty of effective plans use fewer.
How do I write an individual development plan?
Clarify what the plan is for, write down your current context, list strengths, name a development area in plain language, convert it into one specific goal, choose actions that address that gap, note the resources and support involved, decide what evidence would show progress, and set a point to review and revise it.
What is an example of an individual development goal?
A workable one is specific about the capability: “develop experience coordinating a cross-functional project by planning milestones, communicating dependencies and documenting lessons from the project.” Compare that with “become a better leader,” which cannot be acted on or reviewed.
What are some individual development plan examples?
This guide includes complete examples for communication, analytical skills, project management, technical skills, career progression and career change, plus dedicated leadership and manager examples. Each connects strengths, a development area, a goal, actions, support, evidence and a review approach.
What is an individual development plan for leadership?
It is an IDP where the development area is a leadership capability — delegation, decision-making, stakeholder communication, coaching, navigating conflict, strategic thinking or project ownership. Leadership development does not necessarily mean becoming a people manager; project leadership and specialist leadership are separate paths with different plans.
What should a manager put in an individual development plan?
A manager writing their own IDP works from the same structure as anyone else, with development areas drawn from their management practice: delegation, coaching, giving feedback, prioritisation, team communication, cross-functional coordination, decision-making or planning. What suits one manager will not suit another, and there is no single correct management style to develop toward.
Is an IDP only for employees?
No. People at any level write them, including managers and senior specialists, and people also write them independently of any employer. Some organisations run a formal IDP process; many do not use the format at all.
Does my manager need to approve my IDP?
That depends entirely on the organisation. Where the IDP is part of an employer's formal process, there may be an expected review or sign-off. Where you write one for yourself, no approval is involved. Manager involvement is useful when the plan depends on time, budget or an opportunity they control, but it is not universally required.
What is the difference between an individual development plan and a professional development plan?
The terms overlap substantially and some organisations use them interchangeably, so there is no universally accepted distinction. In practice an individual development plan is often a more structured document with defined fields centred on one person's goals, actions, support and evidence, while a professional development plan is often a broader term for development planning generally. If an employer asks for one, it is reasonable to ask what they expect it to contain.
Is an IDP the same as a performance improvement plan?
No. A performance improvement plan is a performance-management process an employer initiates in response to performance concerns. An individual development plan is a development planning tool and is not automatically a disciplinary or corrective process. Some organisations do use development documents within performance processes, so if you are unsure which one you are being asked to complete, ask what it is for and how it will be used.
How often should an IDP be reviewed?
There is no universal frequency. Many people tie the review to the work — at the close of a project, after a set number of attempts at the thing being practised, or at a scheduled development conversation — rather than to a fixed calendar interval. Where an employer runs a formal cycle, that cycle usually sets the rhythm.
Can an individual development plan help me get promoted?
It can help you build capability and evidence that a case for wider responsibility might draw on. It does not guarantee a promotion. Whether one happens depends on openings, organisational structure, budget, timing and decisions made by other people.
Can an individual development plan increase my salary?
Completing an IDP does not determine pay. Compensation is set by employers within markets, and someone can complete a plan in full and see no change in what they earn. Occupational wage data can give useful context when a plan relates to broader responsibilities or a different occupation, but it does not predict any individual's pay.
Keep building on this
Check pay for any occupation and state with the FindMySalary salary checker, or read more career guides.