Most performance reviews cover areas of improvement in some form. A manager mentions communication, time management, or follow-through. The employee nods. The review ends. Three months later, nothing has changed.
I have watched this pattern play out enough times to be confident the feedback itself is rarely the weak link. The process behind it usually is. Real employee improvement needs a clear development goal, a timeline, a check-in, and someone who owns the follow-through.
This guide gives you 45 areas of improvement at work, each with a phrase you can adapt. It also covers how to word them in a performance review, what to say in a job reference, how to answer the question in an interview, and how to build the process that makes any of it stick.
Areas of improvement are specific skills, behaviours, or performance patterns where an employee has a clear opportunity to develop. They are most useful when tied to observable behaviour, linked to business impact, and paired with a concrete next step.
The term covers a wide range of employee development areas.
A gap might be a technical skills deficit, like an employee who needs stronger data analysis capabilities for a role that increasingly depends on reporting.
It might be a behavioural pattern, like someone who consistently misses deadlines because they underestimate task complexity.
Or it might be an interpersonal skills issue, like a manager whose communication style creates friction with their team.
Essential skills for the role, organisational skills, time management skills, leadership skills, problem-solving skills, and conflict resolution skills all fall under this umbrella. So do less visible gaps, like reluctance to share knowledge, difficulty adapting to new processes, or a pattern of agreeing in meetings and then not following through.
What separates useful improvement feedback from vague criticism is specificity. Telling someone they need to communicate better gives them nowhere to start. Telling them their project updates are too infrequent, and that stakeholders are having to chase them for status, gives them something they can act on.
From an HR perspective, identifying skill gaps consistently across the organisation is also valuable data. When the same improvement opportunities surface across multiple teams, that signals a need for training programmes or structured professional development rather than more individual feedback. A skills matrix makes those patterns visible at team level.
These three terms describe the same thing, and you will see all of them used interchangeably in reviews, development plans, and HR templates. The difference between them is tone rather than substance, and picking the right one changes how the feedback lands.
If you have ever wondered whether your review template should say improvement, growth, opportunity, or development, here is how I would separate them.
An area of growth is the same gap framed around future potential instead of current shortfall. The behaviour you are describing is identical. What changes is whether the employee hears a deficiency or a direction.
I would use growth language when someone is already performing well, and the conversation is about what comes next. Telling a strong individual contributor that taking ownership of unowned problems is an area of growth positions it as the path to a bigger role. Calling the same thing an area of improvement makes it sound like a complaint about their current work.
Growth framing works best in career conversations, promotion discussions, and development plans that stretch across more than one review cycle.
An opportunity for improvement frames the gap around what becomes possible once it closes. It is the most neutral of the four terms, which is why it shows up so often in formal review forms and quality frameworks.
Areas of opportunity and opportunity for improvement mean the same thing in practice. Both put the emphasis on the upside rather than the shortfall. If your review template needs language that works for a strong performer and a struggling one without sounding tone deaf in either case, this is usually the safest option.
One caution: because the phrasing is so neutral, it can blur the seriousness of a genuine performance problem. If someone is falling below the minimum standard for the role, say so directly.
Areas of development usually describe longer-horizon capability building rather than a specific behaviour to correct. Think leadership readiness, commercial awareness, or domain depth rather than sending status updates on time.
The practical distinction I use is time. An area of improvement is something you expect to see change inside a quarter. An area of development is something you build over a year or more, often through training, stretch assignments, or a formal development plan.
Both belong in a review. Mixing them without labelling which is which is how employees end up with a list of seven items and no idea where to start.
If you have room for only three, communication, time management, and follow-through cover the majority of what surfaces in performance reviews across roles and seniority levels. Almost every other area on the list below is a more specific version of one of these three.
When someone asks what their top 3 areas of improvement should be, or what three areas need improvement to increase professional performance, this is the honest answer for most people:
Pick one of these three, get specific about what it looks like in this person’s role, and you will have a more useful review than a list of ten generic development areas. The 45 examples below give you that specific version.
The 45 examples below are organised by skill category and written from the manager’s perspective. Each one describes the pattern it addresses and gives you a sample phrase you can adapt. Use them as a starting point and adjust for the individual employee.
1. Written communication. The employee’s written updates are unclear, too long, or too infrequent, creating confusion for teammates or stakeholders.
Example: “Your written project updates have been inconsistent. Stakeholders have had to follow up to understand status. Switching to a weekly summary with three clear fields: what is done, what is next, and what is blocked, would solve most of that.”
2. Speaking up in meetings. The employee has relevant knowledge or concerns but rarely voices them in group settings, which reduces their visibility and the team’s ability to course-correct early.
Example: “You have strong instincts on these projects, but you tend to raise concerns after the meeting rather than during it. Sharing your perspective in the room would make your input more useful and help the team avoid problems earlier.”
3. Adjusting for the audience. The employee communicates well within their own team but struggles to adapt for different stakeholders, which makes cross-functional collaboration harder.
Example: “Your technical communication is strong with the engineering team. Where it breaks down is when you present to leadership or external partners. The level of detail that works internally often creates confusion for non-technical audiences. Working on that translation layer would make you significantly more effective cross-functionally.”
4. Active listening. The employee responds before fully understanding what has been said, which leads to rework, misread requests, and colleagues repeating themselves.
Example: “In our last two planning sessions, you started proposing solutions before the problem had been fully described, and both times the brief shifted afterwards. Summarising what you have heard before responding would save the team a round of rework.”
5. Giving clear instructions. The employee delegates or hands off work with too little context, so the person receiving it has to guess at scope, format, or deadline.
Example: “When you pass work to the team, the brief tends to be a sentence in a message. Twice this quarter that led to someone building the wrong thing. Including the goal, the deadline, and what good looks like would fix most of it.”
6. Asking for clarification. The employee accepts ambiguous instructions without questioning them and then delivers something that does not match the intent.
Example: “You rarely push back when a request is vague, which I think comes from wanting to be low maintenance. In practice, it costs you time. Asking two clarifying questions upfront is faster than redoing the work later.”
7. Presentation skills. The employee’s material is sound, but the delivery buries the point, so decisions get delayed or made on incomplete understanding.
Example: “The analysis in your last deck was strong. The problem was that the recommendation appeared on slide 14. Leading with the conclusion and using the rest to support it would get you a decision in the room instead of a follow-up meeting.”
8. Meeting deadlines consistently. The employee regularly submits work late, or flags blockers too close to the deadline for the team to respond.
Example: “Three of the last five projects came in after the agreed deadline, and in two of those cases the team only found out at the last minute. Building in a checkpoint two days before a deadline to flag risks would give us room to respond.”
9. Prioritising high-impact work. The employee stays busy but directs time toward lower-priority tasks while strategic work gets pushed.
Example: “You are productive, but the pattern I have noticed is that routine tasks get done first and the more complex, higher-impact work gets pushed. Starting the week by anchoring to the two or three things that matter most would shift that.”
10. Estimating task complexity accurately. The employee consistently underestimates how long work takes, which creates pressure at the end of sprints and reduces overall team productivity.
Example: “Your estimates have been running about 40 percent low on complex tasks over the past quarter. Building in a buffer when you scope work, and tracking your estimates against actuals, would help you calibrate over time.”
11. Managing interruptions and protecting focus. The employee is constantly available and reactive, which keeps small requests moving but leaves deep work unfinished.
Example: “You respond to everything within minutes, which the team appreciates. The cost is that your own deliverables slip. Blocking two hours a day where you are not on chat would give you the focus time this role needs.”
12. Declining low-value requests. The employee takes on everything asked of them, which spreads their capacity thin and puts committed work at risk.
Example: “You said yes to four extra projects last quarter, and two of your own deliverables slipped as a result. I would rather you push back on requests that are not on your priority list, or bring them to me so we can decide together.”
13. Planning ahead instead of reacting. The employee handles whatever is in front of them well but rarely looks more than a few days out, so foreseeable problems arrive as emergencies.
Example: “You are excellent under pressure, and I think that is partly why we keep ending up there. Spending 20 minutes at the start of each week mapping what is coming in the next month would let us solve some of these before they become urgent.”
14. Looping in teammates early. The employee works independently to the point where colleagues are surprised by decisions or outputs, which creates friction and rework.
Example: “A pattern that has come up a few times is that you work through a problem solo and share the result, and teammates find out about a decision after it has been made. Bringing people in earlier, especially on anything that affects their work, would reduce friction significantly.”
15. Handling disagreement constructively. The employee pushes back on ideas in ways that shut down conversation rather than opening it up.
Example: “When you disagree with an approach, the way you raise it tends to put people on the defensive. The feedback itself is often valid. Framing it as a question or an alternative rather than a challenge would make the same point land better.”
16. Supporting junior team members. The employee does their own work well but does not actively help less experienced colleagues develop, which limits team-wide capability.
Example: “You have deep expertise the team benefits from, but that knowledge stays with you. Being more available for questions, and sharing your reasoning when you make decisions, would build capability across the team over time.”
17. Sharing credit and recognising others. The employee presents shared work in a way that centres their own contribution, which quietly damages trust across the team.
Example: “In the last two project readouts, the work was described in the first person when three other people had built significant parts of it. Naming contributors explicitly costs you nothing and matters a lot to the people involved.”
18. Working across departments. The employee is effective inside their own function but treats other teams as obstacles rather than partners.
Example: “Your working relationship with finance has been strained for a while, and I think it is because requests go over as demands with short notice. Giving them context and lead time would change the dynamic quickly.”
19. Responding to colleagues in reasonable time. The employee leaves messages and requests unanswered long enough that other people’s work stalls.
Example: “Two people mentioned they wait several days for a reply from you, and in both cases their work was blocked in the meantime. Even a short acknowledgement with a realistic timeline would unblock them.”
20. Taking ownership of outcomes. The employee completes assigned tasks but does not take initiative on problems outside their explicit remit, even when well positioned to address them.
Example: “Your assigned work gets done reliably. The next level for you is taking ownership of problems that do not have a clear owner. When you see something that needs attention, and you are in a position to address it, acting rather than waiting for direction is what distinguishes a strong individual contributor from someone ready for more.”
21. Following through on commitments. The employee agrees to tasks in meetings but does not consistently deliver, which erodes trust with colleagues.
Example: “There have been several instances where you committed to something in a meeting, and it did not happen. Writing down commitments as they are made, and reviewing them before the next interaction, would help close that gap.”
22. Delegating effectively. The manager holds onto work they should be handing over, creating a bottleneck and limiting growth opportunities for their team.
Example: “You are delivering a lot of high-quality individual work, but some of it should be going to your team. You have capable people who are underutilised, and you are creating a dependency that will not scale. Identifying two or three things you can hand off fully this quarter, with proper context and a clear handover, would be a good place to start.”
23. Giving feedback to others. The employee avoids difficult conversations, so problems in their team go unaddressed until they are serious.
Example: “You have mentioned the same concern about a team member to me three times without raising it with them. That conversation is harder now than it would have been in March. Raising things within a week of noticing them keeps them small.”
24. Coaching instead of correcting. The manager fixes their team’s work themselves rather than developing the person who produced it, which keeps quality high in the short term and capability flat in the long term.
Example: “When work comes back below standard, your instinct is to rewrite it yourself overnight. The output is fine, but the same issue reappears next month. Walking the person through what you changed and why would break that loop.”
25. Making expectations explicit. The manager assumes their standards are understood, so their team is judged against criteria nobody has stated out loud.
Example: “Two of your reports have told me they are not sure what good looks like in this role. You have a clear picture of it. Writing it down, even roughly, and going through it in your one-to-ones would remove a lot of guesswork.”
26. Bringing solutions alongside problems. The employee identifies and raises problems but escalates without having worked through the options first.
Example: “You are good at spotting issues early, which is genuinely valuable. The development area is coming to those conversations with one or two options you have considered, even if you are not sure which is right. That shifts the dynamic from escalation to a real problem-solving conversation.”
27. Making decisions under ambiguity. The employee waits for complete information or explicit direction before acting, which creates delays in uncertain situations.
Example: “In ambiguous situations, your default is to pause and wait for clarity. In many cases, that clarity is not coming, and a good-enough decision made quickly beats the right decision made too late. Building your comfort with acting on incomplete information is a concrete goal for the next quarter.”
28. Looking past the immediate fix. The employee resolves symptoms efficiently, but the same issue keeps returning because the underlying cause is never addressed.
Example: “You have handled the same reporting error four times this quarter, each time quickly. What I have not seen is anyone ask why it keeps happening. Spending an hour on the root cause would save you the next four fixes.”
29. Supporting decisions with data. The employee makes reasonable calls based on instinct but cannot show the reasoning, which makes their recommendations harder for others to back.
Example: “Your judgement on this has been right more often than not, which is why I want the reasoning visible. When a recommendation comes with the numbers behind it, other teams can act on it without needing to trust you personally.”
30. Knowing when to escalate. The employee either escalates too early, before attempting a solution, or too late, once the problem has grown.
Example: “The delivery issue in March sat with you for three weeks before it reached me, and by then the options were limited. A simple rule would help: if something has been blocked for more than two days and you do not have a path forward, flag it.”
31. Responding to change constructively. The employee visibly resists changes to priorities or processes, which affects team morale.
Example: “When priorities shift, the way you respond signals to the rest of the team that the change is a problem. Your concerns might be completely valid. The development area is in how they get expressed. Raising them privately and constructively, rather than through visible frustration, would make a significant difference.”
32. Learning new skills and tools. The employee is slow to adopt new tools or workflows and needs more support than peers.
Example: “The transition to the new project management tool took about three times as long for you as for the rest of the team, and some of the old workflow habits have persisted. Being more proactive about getting up to speed on new systems would reduce friction for you and for the people who depend on your work.”
33. Working with shifting priorities. The employee performs well on a stable plan but loses momentum when the plan changes mid-cycle.
Example: “When the roadmap moved in June, your output dropped for about three weeks while you re-planned. Some of that is unavoidable. Rebuilding a rough plan in a day rather than a fortnight would get you moving again faster.”
34. Taking on unfamiliar work. The employee stays inside a narrow set of tasks they already do well and avoids anything that would stretch them.
Example: “You have owned the same three workstreams for two years, and they run beautifully. If you want the next role, I need to see you take something on where you do not already know the answer. Let us pick one this quarter.”
35. Adjusting after feedback. The employee accepts feedback in the moment but their behaviour returns to the previous pattern within a few weeks.
Example: “We agreed in February that briefs would go out before kickoff, and it happened for about a month. Building it into the project template rather than relying on memory would make the change stick.”
36. Reviewing work before submitting. The employee’s work contains recurring errors that a basic review would catch, creating rework.
Example: “There have been four or five instances this quarter where errors in your deliverables required rework after submission. Adding a simple final check before you send anything, even ten minutes, would catch most of these.”
37. Following established processes consistently. The employee shortcuts or ignores agreed processes, which creates inconsistency and compliance risk.
Example: “The documentation process exists for compliance and handover reasons. When it gets skipped, it creates problems for other people further down the line. Consistent process adherence is a non-negotiable at this level.”
38. Documenting work so others can use it. The employee delivers good work but leaves no trail, so colleagues cannot pick it up or repeat it.
Example: “When you were away in July, two people spent a day reverse-engineering a process you run monthly. A short write-up as you go would remove that dependency and make it easier for you to take proper time off.”
39. Consistency across deliverables. The employee’s best work is excellent and their average work is not, which makes their output hard to plan around.
Example: “Your top-end work is some of the strongest on the team. The variation is the issue. When something is not the interesting part of the project, the quality drops noticeably. A consistent baseline matters more than occasional peaks.”
40. Handling routine tasks with care. The employee treats repetitive work as beneath their attention, and the errors show up there rather than in the complex work.
Example: “The complicated parts of your role are handled well. Almost every correction this quarter came from routine tasks. I would rather see the same care applied to both, because the routine work is what other people build on.”
41. Staying current in the role. The employee’s approach has not evolved with their field, and their methods now lag behind the discipline.
Example: “The methods you are using were best practice a few years ago, but the field has moved. Dedicating a few hours a month to staying current, whether through reading, courses, or community engagement, would bring your approach in line with where the discipline is now.”
42. Acting on constructive feedback. The employee receives feedback well but does not follow through, so the same areas surface in review after review.
Example: “This is the third review where we have discussed the same area. The feedback has been consistent and you have agreed with it each time. We need a specific, time-bound action this quarter with a check-in midway so we are not having this conversation again in six months.”
43. Signalling workload pressure early. The employee absorbs an unsustainable workload quietly until quality drops or they burn out.
Example: “You took on three extra projects last quarter without flagging capacity, and the strain showed in October. I need you to tell me when the workload is not realistic. That is information I can act on, and I would rather have it early.”
44. Asking for help sooner. The employee spends significant time stuck on problems that a colleague could resolve in minutes.
Example: “You spent most of a week on the integration issue before mentioning it, and it took Marko about an hour. Getting stuck is fine. Staying stuck for a week is the part I want to change. A two-day rule would work well here.”
45. Setting your own development goals. The employee waits for their manager to define what they should work on rather than taking a view of their own career direction.
Example: “Every development goal you have had in the last two years came from me. I would like the next one to come from you. Where do you want to be in 18 months, and what would you need to build to get there?”
Use this table to scan the full list by skill category and find the review focus for each area. It works well as a prompt sheet before a review conversation.
| Area | Skill category | Review focus |
|---|---|---|
| Written communication | Communication | Format, frequency, audience |
| Speaking up in meetings | Communication | Timing and visibility of input |
| Adjusting for the audience | Communication | Translating for non-technical stakeholders |
| Active listening | Communication | Understanding before responding |
| Giving clear instructions | Communication | Context, deadline, definition of done |
| Asking for clarification | Communication | Questioning vague requests upfront |
| Presentation skills | Communication | Leading with the conclusion |
| Meeting deadlines | Time management | Checkpoints and early escalation |
| Prioritising high-impact work | Organisational skills | Weekly anchoring to top priorities |
| Estimating task complexity | Time management | Buffer-building and tracking actuals |
| Managing interruptions | Time management | Protected focus blocks |
| Declining low-value requests | Organisational skills | Capacity boundaries |
| Planning ahead | Organisational skills | Looking a month out, not a week |
| Looping in teammates early | Interpersonal skills | Earlier involvement on shared decisions |
| Handling disagreement | Interpersonal skills | Framing and delivery of concerns |
| Supporting junior colleagues | Interpersonal skills | Availability and knowledge sharing |
| Sharing credit | Interpersonal skills | Naming contributors explicitly |
| Working across departments | Collaboration | Context and lead time for other teams |
| Responding in reasonable time | Collaboration | Acknowledgement and realistic timelines |
| Taking ownership | Leadership skills | Acting without being asked |
| Following through on commitments | Leadership skills | Written tracking of commitments |
| Delegating effectively | Management skills | Structured handover of routine work |
| Giving feedback to others | Management skills | Raising issues within a week |
| Coaching instead of correcting | Management skills | Developing the person, not just the output |
| Making expectations explicit | Management skills | Writing down what good looks like |
| Bringing solutions | Problem-solving | Coming to conversations prepared |
| Deciding under ambiguity | Problem-solving | Acting on good-enough information |
| Looking past the immediate fix | Problem-solving | Root cause over symptom |
| Supporting decisions with data | Problem-solving | Making the reasoning visible |
| Knowing when to escalate | Problem-solving | A clear trigger for raising blockers |
| Responding to change | Adaptability | Raising concerns constructively |
| Learning new skills and tools | Adaptability | Proactive self-directed onboarding |
| Working with shifting priorities | Adaptability | Fast re-planning after a change |
| Taking on unfamiliar work | Adaptability | Stretch beyond the known set |
| Adjusting after feedback | Adaptability | Making the change structural, not memory-based |
| Reviewing own work | Attention to detail | Simple final check before sending |
| Following processes | Attention to detail | Treating process as non-negotiable |
| Documenting work | Attention to detail | Removing single-person dependencies |
| Consistency across deliverables | Quality of work | A reliable baseline, not occasional peaks |
| Handling routine tasks with care | Quality of work | Same standard for dull and interesting work |
| Staying current | Professional development | Regular investment in the domain |
| Acting on feedback | Professional development | Time-bound action with a check-in |
| Signalling workload pressure | Self-management | Flagging capacity before quality drops |
| Asking for help sooner | Self-management | A time limit on being stuck |
| Setting own development goals | Professional development | Employee-led career direction |
In a performance review, an area of improvement should name an observable behaviour, describe its impact, and propose a change that can be checked later. Anything that misses one of those three parts will read as an opinion.
Most of the weak feedback I read fails at the same point. It describes a trait instead of a behaviour, or it describes a behaviour without saying why it matters. Both leave the employee with nothing to act on.
Write the behaviour first, the impact second, and the change third. If you follow that order, the sentence almost writes itself.
Compare these two versions of the same feedback:
Weak: “Needs to improve communication.”
Strong: “Project updates have gone out irregularly this quarter, and the sponsor has had to ask for status twice. A short weekly update covering done, next, and blocked would remove that.”
The second version can be evaluated in eight weeks. The first cannot be evaluated at all.
A few rules I would hold to in any review form:
These phrases are written to be adapted rather than copied word for word. Swap in the specific behaviour, the real number, and the change you want to see.
| Area | Phrase you can adapt |
|---|---|
| Written communication | “Updates have been going out irregularly, and stakeholders have had to chase for status. A fixed weekly summary would close that gap.” |
| Meeting deadlines | “Three of five projects came in late this quarter, and the team found out close to the deadline. A checkpoint two days out would give us room to respond.” |
| Prioritisation | “Routine work is getting done ahead of higher-impact work. Anchoring each week to the top two priorities would rebalance that.” |
| Collaboration | “Decisions that affect other people are being made solo and shared afterwards. Bringing colleagues in earlier would reduce rework.” |
| Ownership | “Assigned work is delivered reliably. The next step is picking up problems that do not yet have an owner.” |
| Delegation | “Work that could sit with the team is staying with you, which creates a bottleneck. Handing over two areas fully this quarter would help.” |
| Problem-solving | “Issues are being raised early, which is valuable. Bringing one or two options alongside them would move the conversation forward faster.” |
| Adaptability | “Concerns about changing priorities are coming through as visible frustration. Raising them directly and privately would land better.” |
| Attention to detail | “Several deliverables needed rework for avoidable errors. A short final check before sending would catch most of them.” |
| Follow-through | “Commitments made in meetings are not consistently landing. Writing them down as they are made would close the gap.” |
| Acting on feedback | “We have discussed this area in three reviews. Let us agree one specific action this quarter with a check-in at six weeks.” |
| Professional development | “The approach here has not changed in a while and the field has. A few hours a month on staying current would bring it up to date.” |
If you are choosing a system to run these cycles in, our roundup of performance review software compares the main options. If you are earlier in the process, we also cover how to choose performance review software.
A review that only lists areas of improvement gives the employee no reference point for what to keep doing. The two halves of the conversation are equally specific or the whole thing loses credibility.
When someone asks what is going well at work, or what they do well, they are usually asking for the same specificity they get on the improvement side. “You are a great team player” is as useless as “needs to improve communication.”
A useful strengths statement follows the same shape: behaviour, impact, and a note on where it could be applied more widely. For example, “Your handover documentation is the clearest on the team, and two people have told me it saved them a day each. I would like the rest of the team to use it as the standard.”
Employees often find the strengths half harder to answer than the improvement half, particularly in a self-evaluation. Our guide to self-evaluation examples covers how to write both sides without either overclaiming or underselling.
The most useful version of this exercise pairs each strength with a related area of improvement, so the development conversation builds on something that already works. Listing three of each in isolation is a much weaker use of the same effort.
This question comes up in performance reviews, self-assessments, interviews, and reference requests. In every one of those settings, the pairing is what makes the answer credible.
Here is what I mean in practice:
| Strength | Paired area of improvement | Why they connect |
|---|---|---|
| Deep technical expertise | Sharing knowledge with the team | The expertise is real, and it currently stays with one person |
| Fast, decisive execution | Looping in stakeholders earlier | Speed is the strength, and it is also what creates the surprise |
| High standards on own work | Delegating and coaching others | The standard is the asset, and holding it alone is the bottleneck |
| Strong relationships inside the team | Working across departments | The skill exists, and it has not been applied outside the function |
| Reliable delivery of assigned work | Taking ownership of unowned problems | Reliability is the foundation, and initiative is the next level |
| Clear written communication | Speaking up in group settings | The thinking is good, and the room is not hearing it |
A pairing like this does two things. It makes the improvement area feel like a natural extension rather than a criticism, and it tells the employee which existing habit to lean on when they work on it.
If you are on the receiving end of this question and need to answer it about yourself, pick strengths you can evidence, then choose improvement areas that are genuinely adjacent to them. An answer where the three strengths and three areas of improvement have nothing to do with each other reads as a list assembled to fill a form.
In a reference, name one real area of improvement, keep it developmental, and pair it with context that shows it is manageable. Claiming someone has no areas of improvement damages your credibility and does not help them.
Reference requests almost always include some version of this question, often phrased as the top three ways this person could improve their work performance. Two answers fail immediately. Saying there is nothing sounds evasive. Listing three genuine weaknesses without context reads as a warning.
What works is one area, described as a development stage rather than a flaw, with evidence that the person was already working on it.
For example: “The main area we worked on together was delegation. She held onto detailed work longer than she needed to as her team grew. She recognised it, handed over two workstreams last year, and the team is stronger for it.”
That answer is honest, it is specific, and it makes the candidate look self-aware rather than deficient.
Three things I would avoid in a reference:
Check your organisation’s reference policy before you answer. Many companies limit what managers can confirm beyond dates and job title, and in some jurisdictions the wording of a reference carries legal weight.
Name one genuine area, show what you have already done about it, and say what has changed as a result. The interviewer is testing self-awareness and follow-through rather than looking for a weakness.
The classic mistake is the disguised strength. “I care too much” or “I work too hard” tells the interviewer you either lack self-awareness or are not willing to be straight with them. Neither helps you.
A structure that works:
For example: “I used to take on requests without checking my capacity, and last year two of my own deliverables slipped because of it. I started keeping a visible priority list and taking new requests to my manager before agreeing to them. Since then I have not missed a committed deadline, and I am better at saying no early.”
Choose an area that is real but not central to the job you are interviewing for. If the role is 80 percent stakeholder management, do not pick stakeholder management. Pick something adjacent that you have made measurable progress on.
Manager development areas are usually about what they do through other people rather than what they produce themselves. Most managers who struggle were promoted for individual excellence and never coached on the shift.
The most common areas of improvement for managers I see are these six:
The one-to-one is where most of these either work or fall apart. If your managers are running check-ins that feel like status meetings, our list of one-on-one meeting questions gives them a better starting point.
One structural note. If a manager’s team includes people who also report into another leader, some of what looks like a management gap is actually an unclear reporting structure. Dotted line reporting explains how to set expectations when two managers share responsibility for the same person.
Look for patterns across several data points rather than impressions from the last few weeks, then pick one to three areas per cycle. Applying the same generic list to everyone is the most common mistake I see.
Four sources of information produce the most accurate picture of employee performance:
Once you have these inputs, prioritise one to three improvement areas per cycle rather than listing everything. A review that surfaces seven improvement opportunities gives an employee nowhere to start. One or two, each with a clear path forward, is actionable.
For HR teams, this is also where aggregate patterns become useful. When the same skill gaps surface across multiple departments, the solution is structural: targeted training, a skills workshop, or a new onboarding component rather than more individual feedback. Tracking those patterns alongside your other HR metrics to track [INTERNAL LINK – confirm slug] turns review data into something leadership can act on.
Constructive feedback works when it is specific, behavioural, and forward-facing. Vague feedback creates defensiveness and leaves the employee with nothing to work with.
A few principles that make a real difference in how employees receive improvement feedback:
A development plan turns an area of improvement into a structured commitment with a named goal, a timeline, a check-in date, and a way to track progress. Feedback without one is just a conversation.
A strong development plan has four elements:
The difference between a weak and a strong version:
Weak: “Work on leadership skills.”
Strong: “By the end of Q3, run two cross-functional project kick-offs without manager involvement. Check in at the six-week mark to review how the first one went.”
The second version has something to evaluate. It creates accountability in both directions, for the employee to act and for the manager to follow through.
A development plan without a check-in date gets forgotten. Agree a specific date, four to six weeks out, before the review conversation ends.
The check-in does not need to be long. Twenty minutes focused on one question is enough: is the change happening? If your managers already run regular one-to-ones, fold it into those rather than adding a separate meeting.
Development plans stored in a shared document tend to disappear between cycles. The manager moves on, the file gets buried, and the next review starts from scratch.
When development goals live inside a performance management system alongside the employee record, they stay visible, carry forward into future cycles, and build a longitudinal picture of professional growth. HR teams can see which employees have open goals, which check-ins are overdue, and which skill gaps keep recurring across the organisation.
The three failures I see most often are waiting for the annual review, listing too many areas at once, and giving no path forward. Each one is easy to fix once you name it.
Waiting until the annual review. An annual review is the wrong place for someone to hear about an area of improvement for the first time. If a pattern has been visible for six months, the employee should have known six months ago. The formal review works best as a summary of what has already been discussed.
Listing too many areas at once. A review that identifies seven improvement opportunities sends a demoralising message and gives the employee no clear priority. Pick the one or two areas with the biggest impact on their current performance and career growth. Address the rest when those are under control.
Giving no path forward. Telling someone they need to improve, without specifying what improvement looks like, how it will be measured, and when you will check in, is feedback with no mechanism for change. Every improvement area raised in a review should leave the conversation with a concrete next action, a timeline, and a follow-up date.
Thrivea’s performance management module lets you build review cycles, set development goals, and track progress against them over time, all connected to the employee record. The goal is to keep improvement areas visible between review cycles rather than only inside them.
Managers can create a goal from a review, assign it to an employee, and give it a target date without leaving the cycle. The improvement area you discussed becomes a tracked commitment rather than a note in a form.
Goals support live progress updates and key results, so both the manager and the employee can see whether the change is happening. When the next cycle opens, that history is already there and you are reviewing progress against a plan instead of starting over.
The people goals view shows every open goal across a team in one place, including who is on track and who needs support. Managers can update statuses or assign new goals from the same screen.
Review cycles support custom roles, timelines, and rating scales, with a drag-and-drop form builder for the questions themselves. If your review template already separates strengths from areas of improvement, you can reproduce that structure directly.
See how performance management works in Thrivea or start free.
Identifying areas of improvement is the straightforward part, and making the feedback mean something after the review ends is where most processes fall down. The 45 examples above give you the language. The process around them decides whether anything changes.
Pick one or two areas per person. Word them as behaviour, impact, and change. Pair each one with a strength the employee can build on. Agree a check-in date before the conversation ends, and track the goal somewhere it will still be visible in three months.
That follow-through is what separates organisations where performance reviews drive real improvement from ones where the same feedback gets repeated year after year.
For most people, the answer is communication, time management, and follow-through on commitments. Almost every other development area is a more specific version of one of these three. Pick the one with the biggest effect on your current role, get specific about what it looks like day to day, and work on that first.
Name one genuine area in behavioural terms, give a short example of where it showed up, say what you changed, and describe what is different now. Avoid disguised strengths like caring too much, which read as evasive rather than self-aware.
A common set of five is communication, time management, collaboration, adaptability, and attention to detail. I would not put five in a single review, though. One to three is the practical ceiling for anything you want the employee to actually act on.
Sending a fixed weekly status update instead of ad hoc ones. Flagging deadline risks two days out instead of on the day. Bringing one or two options to a problem instead of escalating it raw. Handing over two workstreams to your team instead of holding them. Each one is specific enough to check in eight weeks.
Answer this the same way you would answer the improvement question, with behaviour and impact rather than adjectives. “My handover documentation is the clearest on the team and saved two colleagues a day each” is useful. “I am a team player” is not. If you are filling in a self-evaluation, our self-evaluation examples guide covers both halves.
Start with a specific observable behaviour rather than a general trait. Describe its impact on the team, the work, or the business. Then propose one concrete change and a way to measure it. The phrase table above gives you a starting point for the twelve most common areas.
One to three is the practical ceiling for a review meant to drive real change. More than three is overwhelming, and it often signals that feedback has not been given continuously through the year. If there are more than three genuine development areas, prioritise the ones with the greatest impact on current performance, or the ones that are prerequisites for the others.
An area of improvement is a development opportunity for someone who is otherwise performing at or above expectations. A performance issue is a pattern that falls below the minimum standard for the role. The second needs a different process, usually a formal performance plan, and neutral language like “opportunity for improvement” can obscure that difference if you are not careful.
Both, at different levels. Managers own the individual conversations: identifying areas for improvement, delivering feedback, setting development goals, and running check-ins. HR owns the process that makes those conversations happen consistently: designing review cycles, building the templates managers use, spotting skill gaps at team or company level, and making sure development plans get tracked rather than forgotten.
A performance review template gives every manager the same form for rating work, writing feedback, and setting next goals. Below you'll find a free...
Your designer formally reports to the Head of Marketing. But every Monday, the Product Lead sits down with them and sets their priorities for the week...
A manager is staffing a new project and needs someone who knows a specific tool inside out. They scroll through old performance reviews, message a few...
