performance, feedback, employee recognition, constructive criticism,

Constructive Feedback Examples: 60 Phrases That Work (+ Areas of Improvement)

Stas Kulesh
Stas Kulesh Follow
Sep 17, 2026 · 31 mins read
Constructive Feedback Examples: 60 Phrases That Work (+ Areas of Improvement)
Share this

Constructive feedback is specific, actionable information about a behaviour or output that helps the recipient understand what to change and why — delivered in a way that the person can hear and act on without becoming defensive.

The word “constructive” does the most important work in that definition. Feedback is constructive when it builds toward something — a specific improvement, a clearer understanding, a concrete change. It is not constructive when it describes a problem without suggesting a direction, criticises a person rather than a behaviour, or arrives so vaguely that the recipient does not know what to do differently.

This guide has 60 specific constructive feedback examples organised by situation, 30 areas of improvement examples with ready-to-use phrases, and a clear framework for delivering feedback that actually changes something.


What is constructive feedback? The definition

Constructive feedback is feedback that identifies a specific behaviour or outcome that needs to change, explains the impact of the current approach, and suggests or invites a concrete alternative — delivered in a way that preserves the recipient’s dignity and their ability to act on it.

Constructive feedback is distinct from criticism (which identifies a problem without necessarily offering direction), praise (which acknowledges what is working without necessarily being specific about what to continue), and evaluation (which assesses performance without necessarily being actionable).

The four elements of genuinely constructive feedback:

Specific — it describes a particular behaviour, decision, or output rather than a general impression. “You interrupted Sarah twice in the meeting before she finished her point” is specific. “You’re not a good listener” is not.

Behavioural — it focuses on what the person did, not who they are. Behaviours can be changed; character cannot. “The email was sent without the client copied” is behavioural. “You’re careless with clients” is a character assessment.

Impact-connected — it explains why the behaviour matters and what effect it had. Without the impact, the person does not understand why the change is important. “When the report arrived the day before the deadline, the team didn’t have time to review it — which affected the quality of what we presented to the client” is impact-connected.

Forward-looking — it points toward what to do differently rather than dwelling on what went wrong. “In future, flagging two days before the deadline rather than one would give the team time to review” is forward-looking.


What is constructive criticism?

Constructive criticism is feedback that identifies something that is not working and suggests how to improve it. The term is often used interchangeably with constructive feedback, though “criticism” specifically implies that something needs to change, whereas “feedback” can be positive or developmental.

Constructive criticism works when it is: specific about the problem, clear about the impact, honest about what is not working, and generous with suggestions for improvement. It fails when it is vague, personal rather than behavioural, delivered at the wrong time or in the wrong setting, or so softened by qualifications that the actual message gets lost.

The most common failure mode in constructive criticism is the “feedback sandwich” — positive observation, criticism, positive observation — which has been shown to reduce the effectiveness of the critical message because recipients remember the positives and discount the criticism. Direct, respectful feedback without excessive cushioning is more effective and more honest.


How to give constructive feedback — the framework

The most reliable framework for constructive feedback in a workplace context is the SBI model: Situation, Behaviour, Impact.

Situation — describe the specific context. When and where did the behaviour occur? “In the client meeting on Tuesday” is better than “sometimes” or “recently.”

Behaviour — describe the specific behaviour, not the interpretation of it. What exactly did the person do or not do? “You presented the revised timeline without mentioning that two deliverables had moved” is a behaviour. “You misled the client” is an interpretation.

Impact — describe what happened as a result. What was the effect on the project, the team, or the client? “The client was surprised in the follow-up call when they saw the revised dates, which damaged their confidence in the plan” is an impact statement.

Then — ask or suggest: what would have been better, and what should happen differently going forward?

What good delivery looks like: Private rather than public — feedback on something the person needs to change should not arrive in a setting where they feel humiliated. Direct rather than circuitous — vague hints do not produce change. Timely — close to when the behaviour occurred, while the context is fresh. Two-directional — the person should have the opportunity to respond, explain, or add context.


Constructive feedback examples for colleagues

These are written peer-to-peer — from one colleague to another — for informal feedback conversations or structured peer review processes.

On communication

“In the project planning meeting, I noticed you shared the updated timeline without flagging that two milestones had moved. The rest of the team found out from the client rather than from us — which made the situation harder to manage. In future, flagging timeline changes before the external call would give us time to align on how to communicate them.”

“I’ve noticed that your written updates are often missing the ‘so what’ — they describe what happened but don’t say what it means for next steps. Adding a one-sentence conclusion about what the team should do with the information would make them significantly more useful.”

“During the design review, you pushed back on several ideas before they were fully presented. I think some of those ideas had merit that got lost in the pushback. Could we try letting the presenter get through their full pitch before we engage critically?”

“The email you sent to the whole team about [issue] felt like it was directed at one person rather than the group. It put everyone in an uncomfortable position. If the issue is with one person’s work, a direct conversation would be more effective and less awkward for everyone else.”

“In the client call yesterday, you answered a question I’d been asked directly before I’d had a chance to respond. I know the intention was to keep things moving, but it left the client unsure who owns that workstream. Letting me take the questions in my area — and adding afterwards if something is missing — would make the ownership clearer.”

On quality and delivery

“The deliverable you sent over had some sections that needed significant editing before I could pass it to the client. I’m not sure if there was a time pressure I wasn’t aware of — but if you’re up against a deadline, flagging it earlier would help us figure out together whether to adjust the scope or ask for more time.”

“The analysis you shared was solid, but the conclusion didn’t follow clearly from the data you presented. Walking through the logic — even briefly — would make the recommendation much easier to act on.”

“I’ve seen a few instances where tasks you’ve committed to arrive later than expected without a heads-up. This makes it harder to plan. Even a brief message the day before if something is slipping would make a big difference.”

“The last two handovers came without the context I needed to pick the work up — the files were there but not the decisions behind them. I ended up reconstructing your reasoning or asking you to re-explain it. A few lines on what you tried and why you settled where you did would save us both that round trip.”

“When we reviewed the spec together you agreed with the approach, but the implementation went a different way without us discussing it. The new approach may well be better — what I’d ask is that we talk about the change before it lands, so I’m not reviewing something I don’t recognise.”

On teamwork and meetings

“You left the retrospective early before we got to the action items. Those are the most important part, and your absence meant we didn’t have your perspective on your workstream. I know schedules are tight — but if you need to leave early, could you flag it at the start so we can prioritise your items?”

“When [colleague] was presenting, I noticed you were on your phone for a significant portion of it. Whether or not that was the intention, it signals disengagement — and it affects how willing people are to put effort into presenting when they feel the audience isn’t there.”

“In planning sessions, you often raise the objection that ends the discussion rather than the one that moves it forward. The concerns are usually valid — what’s missing is a suggestion of what to do instead. Pairing the objection with an alternative would make those conversations a lot more productive.”

“We agreed in the last retro that [action] was yours to pick up, and it hasn’t moved since. If it turned out to be bigger than it looked or the priority changed, that’s fine — but saying so in the channel would stop the rest of us planning around something that isn’t happening.”

“You tend to make decisions that affect my workstream in side conversations rather than in the meetings where we’re all present. I usually agree with the outcome, so this isn’t about the decisions themselves — it’s that I find out late and can’t contribute the context I have.”


Constructive feedback examples for employees

These are written manager-to-employee — for 1:1 conversations, performance reviews, or documented feedback.

On ownership and initiative

“I’ve noticed that when you hit a blocker, you tend to wait until our next scheduled check-in rather than flagging it immediately. Three times in the past quarter, this caused delays that would have been avoidable. Going forward, please reach out the same day you identify a blocker — even a quick Slack message is enough. The sooner we know, the sooner we can unblock.”

“The project you led in Q3 was well-executed tactically, but the scope expanded significantly without a conversation about whether that was appropriate. I’d like you to develop the habit of checking in when scope changes — not to get permission for everything, but to make sure we’re aligned before significant new work begins.”

“You consistently deliver what is asked, but I rarely see you anticipate what’s needed next. The next step in your development is moving from ‘completing tasks’ to ‘managing outcomes’ — which means thinking ahead about what the work requires, not just what you’ve been asked to do.”

“When something goes wrong on your projects, the explanations tend to focus on what other teams or circumstances did. Some of that is fair — but I’d like to hear more about what you would do differently next time. Owning your part of it, even when it’s the smaller part, is what makes the difference between a contributor and someone who can run the work independently.”

“You often bring me problems at the point of asking what to do rather than with a recommendation. You have better context on these than I do, so my answer is usually just ratifying what you already think. Bring me your proposed answer alongside the problem — I’ll say if I disagree, and you’ll spend far less time waiting on me.”

On communication and stakeholder management

“The update you sent to senior leadership last week included raw data without context or a recommended interpretation. Leadership is looking for a view, not just numbers. Going forward, every update should include a two-sentence summary of what the data means and what — if anything — you think should happen as a result.”

“In the client presentation, you avoided a question that made you uncomfortable rather than answering it or acknowledging you would follow up. The client noticed the evasion. A direct ‘that’s a good question — let me get you the accurate answer by Thursday’ is always better than pivoting away.”

“I’ve had feedback from two colleagues that your tone in written communication can read as abrupt, particularly when you’re under pressure. I don’t think it’s intentional — but impact matters regardless of intention. It would help to read your messages once before sending and ask whether they’d land well if you received them.”

“In cross-functional meetings you explain your work at a level of technical detail that loses most of the room. The content is right; the calibration isn’t. Leading with the decision or the impact, and keeping the detail for whoever asks, would get you far more traction with those audiences.”

“Your status updates tend to say a piece of work is ‘nearly done’ for several weeks running. I don’t think anything is being hidden — I think ‘nearly done’ is doing too much work as a phrase. Naming what specifically remains, and what could still go wrong, would give both of us a much more reliable picture.”

On quality and standards

“Several of your recent deliverables have had errors that a careful review would have caught. I understand there is time pressure, but submitting work with avoidable errors affects your credibility and creates extra work for everyone downstream. I’d like you to build a review step into your workflow before anything goes to a client or another team.”

“The code you submitted in the last sprint worked but wasn’t documented. Other developers cannot maintain or build on undocumented code — which creates a problem that outlasts the original delivery. Going forward, documentation is part of the definition of done, not optional.”

“You tend to treat the first working version as the finished one. On [recent example] the initial approach shipped even though a second pass would have made it substantially simpler to maintain. Building in a deliberate ‘is this the version I want to defend in six months’ check before you call something done would raise the standard of your work.”

“When you receive review comments, the changes get made but the underlying pattern often reappears in the next piece of work. That suggests the feedback is being applied literally rather than generalised. It would help to spend a few minutes after each review asking what the comment says about how to approach the next thing, not just this one.”

“Work that goes to an internal audience is noticeably rougher than work that goes to clients. I understand the instinct to prioritise, but colleagues are making decisions off your internal output, and errors there cost us just as much — they’re simply less visible. The standard should be the same for both.”

On growth and development

“You’re performing well in your current role, but I think you’re playing it too safe. You have the skills to take on more complex problems, but I see you consistently choosing the more defined tasks. I’d like to give you a more ambiguous project next quarter — one without a clear answer — to see how you approach it.”

“The feedback you give in code reviews tends to be technical and accurate but misses the broader context of why a decision was made. Adding a sentence of context — ‘the reason this matters is X’ — would make your reviews significantly more useful for the person on the receiving end.”

“You’ve told me you want to move toward [role or level], and the work you’re doing is strong — but it’s all inside your own remit. The gap between where you are and that next step is visibility and influence outside this team. Over the next quarter I’d like you to take one piece of work that requires you to bring another team along with you.”

“When a piece of work is going badly, you tend to go quiet and try to fix it alone before telling anyone. I understand the instinct, but it means help arrives late and the problem is bigger by then. I’d rather hear about it early and be wrong than hear about it on time and be too late — raising it is not an admission of failure.”

“You’ve been doing work above your current level for a while now, and I want to be straight with you about what’s missing rather than letting you guess. The delivery is there; what isn’t yet is the track record of leading something contentious end to end. That’s the gap we should aim at this year, and I’ll find you the opportunity.”


Constructive feedback examples for managers

These are written employee-to-manager — for upward feedback, 360 reviews, or structured feedback sessions. Upward feedback is the hardest kind to give and the most valuable kind to receive.

On communication and direction

“In the last two sprints, priorities changed mid-sprint without an explanation of why. The team adapted, but without context for the change it was hard to make good decisions about trade-offs. Even a brief Slack message explaining the reasoning would help the team understand the bigger picture and make better calls independently.”

“The feedback I receive from you tends to arrive at the end of a project rather than during it. By the time I hear that something wasn’t quite right, the work is done and I can’t apply the learning immediately. More frequent, smaller feedback loops during the project would help me course-correct in real time.”

“I’ve noticed that in team meetings, certain voices consistently get more airtime than others. The quieter contributors have valuable perspectives — it would help if the meeting format created more space for everyone, perhaps through explicit invitation or structured turns.”

“When leadership decisions come down to us, they tend to arrive as instructions without the reasoning attached. The team follows them either way, but we can’t anticipate the next one or explain it to anyone else. If you can share even the parts of the rationale that aren’t confidential, we’d spend a lot less time speculating.”

“Everything on the roadmap is currently framed as equally urgent, which in practice means the team decides the real priorities by itself — usually without the context you have. I’d find it much more useful to hear explicitly what should slip if something has to.”

On support and development

“I’ve asked about a development opportunity twice in our 1:1s and both times the conversation moved on without a concrete outcome. I’m not sure if this is a priority for you or whether there are constraints I don’t know about — but a direct answer, even if it’s ‘not right now because X’, would help me understand where I stand.”

“When I flag concerns in our 1:1s, I sometimes feel they are acknowledged but not acted on. I don’t need every concern to result in immediate action — but knowing that you’ve taken it seriously and here’s your view would help me trust that raising issues is worthwhile.”

“The way decisions are communicated to the team often doesn’t include the reasoning. When we understand why a decision was made — especially a difficult one — we can support it and explain it to others. Decisions communicated without context tend to generate rumour and uncertainty.”

“Our 1:1s have become status meetings — we go through the list and the time is gone. I can give you a written update before we meet. What I’d get more from is using that half hour for the things that don’t fit in a status update: where I’m stuck, and where I’m trying to get to.”

“You often step in and take over a task when it’s going slowly rather than letting me work through it. The immediate problem gets solved, but I don’t learn the thing that would stop it recurring. I’d rather you let me finish it — even a bit slower — and tell me afterwards what you’d have done differently.”

On workload and team health

“The team has been at or above capacity for three consecutive quarters, and each new request has been absorbed rather than traded against something existing. People are managing, but the cost is showing in [specific signal]. I think we need an explicit conversation about what comes off the list, not just what goes on it.”

“When you’re under pressure, it becomes visible to the team quickly — short replies, cancelled 1:1s, a noticeably different tone. People start managing around your mood instead of raising things. I’m not asking you to hide it; naming it directly would stop us reading it as displeasure with us.”

“You approve time off readily, which I appreciate, but you’re also visibly online through your own. That sets the real expectation regardless of what the policy says. If you took your leave properly, the rest of us would feel far more able to.”

“Two people have left this team in the past year and I don’t think either exit conversation reached you honestly. I’d like to see us do something more structured than the standard HR process — even an informal conversation a month after someone leaves would surface more than we’re currently learning.”

“Recognition in this team tends to go to whoever presented the work rather than whoever did the difficult part of it. [Name] is the clearest recent example. It would make a real difference if the credit named contributions rather than defaulting to the most visible person.”


Constructive feedback examples for performance reviews

These are structured for written performance review documentation — longer, more formal, appropriate for HR records.

“[Name] consistently delivers high-quality work within agreed timelines and has demonstrated strong technical skills in [area]. The primary development area for the coming period is stakeholder communication: specifically, providing proactive updates when circumstances change rather than waiting until the next scheduled check-in. Three instances this quarter — [examples] — resulted in stakeholders being surprised by information they should have received earlier. Building a habit of real-time communication when plans change would make [Name]'s work significantly more impactful at the stakeholder level.”

“[Name] is a valued technical contributor and their output quality is consistently high. The area I would like to see develop over the next period is cross-functional influence — specifically, building relationships with teams outside their immediate workstream and proactively sharing relevant context across those relationships. [Name] currently operates primarily within the team, which limits the broader impact they could have.”

“[Name] has shown genuine growth in [area] since their last review. The development focus for the coming period is time management under competing priorities: on three occasions this quarter, [Name] struggled to navigate competing deadlines effectively, resulting in [impact]. Working with [Name] on a prioritisation framework and building the habit of flagging conflicts early are the agreed next steps.”

“[Name] has met the objectives set at the last review and performs reliably within their defined scope. The development area for the coming period is decision-making without escalation: a significant proportion of decisions well within [Name]'s remit are currently routed to me for confirmation, which slows delivery and limits their growth. We have agreed that [Name] will decide and inform rather than ask on all matters within [defined scope], escalating only where the impact extends beyond their team.”

“[Name]'s domain expertise in [area] is among the strongest on the team and colleagues consistently seek them out for it. The development focus for the coming period is scaling that expertise beyond individual conversations. Knowledge currently resides largely with [Name], which creates a dependency and limits the team’s overall capability. Agreed next steps are documenting the two most frequently requested areas and running a session for the wider team by [date].”

“[Name] has delivered [specific achievement] this period, which had a measurable impact on [outcome]. The area for development is consistency of quality across the full range of their work: output produced under time pressure has shown a noticeably higher error rate than work with adequate lead time — [specific examples]. Rather than treating this as a care issue, we have agreed it is a planning one, and [Name] will build explicit review time into estimates going forward.”

“[Name] works effectively with their immediate team and is well regarded within it. The primary development area is influence beyond that boundary: on [specific project], a decision made by another team created significant rework that earlier engagement would likely have prevented. [Name] is not expected to have authority over those teams, but is expected to build the relationships that surface such decisions before they are final. We have agreed a specific set of relationships for [Name] to develop this period.”

“[Name] responds constructively to direct feedback and has acted on every point raised in our 1:1s this period. The development area is self-assessment: [Name] tends to evaluate their own work either considerably more harshly or more favourably than the evidence supports, which makes prioritising their development harder than it needs to be. The agreed approach is a short written self-review before each 1:1, compared against outcomes, to calibrate that judgement over time.”

“[Name] has taken on additional responsibility this period following [change], and has handled the increased scope competently. The development focus is delegation: [Name] continues to perform tasks personally that should now sit with others on the team, which limits both their own capacity and their team’s development. We have agreed on three specific responsibilities to transfer by [date], with [Name] retaining oversight rather than execution.”

“[Name] is dependable in execution and has closed out every commitment made this period. The development area is forward planning: [Name]'s contributions are strongest once a direction has been set and less visible while it is being decided, which means their expertise arrives later in the process than it should. Over the coming period we have agreed that [Name] will join [specific planning forum] and prepare a point of view ahead of each session rather than responding to conclusions already reached.”


Areas of improvement examples — 30 phrases ready to use

Areas of improvement are specific capabilities or behaviours that would make someone more effective in their role. In performance reviews, they should be as specific as constructive feedback — naming the exact capability and why it matters.

Communication

  • “Proactive stakeholder updates when plans change”
  • “Clearer written communication — conclusions stated before supporting detail”
  • “More structured verbal presentation in meetings”
  • “Improving response time on time-sensitive communications”
  • “Reducing jargon in cross-functional communication”

Delivery and reliability

  • “Earlier escalation when a deadline is at risk”
  • “More accurate time estimation for complex tasks”
  • “Building a review step before submitting work”
  • “More consistent follow-through on committed actions from meetings”
  • “Managing multiple deadlines simultaneously without loss of quality”

Collaboration

  • “More active contribution in team discussions”
  • “Giving feedback earlier in the process rather than at final review”
  • “Being more receptive to alternative approaches in planning discussions”
  • “Improving how disagreement is expressed — direct but not dismissive”
  • “Proactively sharing context with adjacent teams”

Strategic thinking

  • “Moving from task completion to outcome ownership”
  • “Considering downstream impact before proposing changes”
  • “Anticipating stakeholder questions before a presentation”
  • “Building a stronger understanding of the business context driving priorities”
  • “Identifying the root cause rather than treating the surface symptom”

Leadership and influence

  • “Creating more space for quieter voices in meetings”
  • “Giving more specific feedback to direct reports”
  • “Delegating more effectively rather than absorbing all execution”
  • “Building relationships across the organisation, not only within the team”
  • “Communicating decisions with more context and reasoning”

Personal effectiveness

  • “Reducing the time spent in reactive mode vs proactive work”
  • “Asking for help earlier when blocked”
  • “Being more comfortable with ambiguity and incomplete information”
  • “Applying learning from one project more explicitly to the next”
  • “Setting and protecting time for deep work”

3 key strengths and 3 areas of improvement — examples

This format is commonly used in peer reviews and self-assessments. Here are complete examples.

Example 1 — Software engineer

3 key strengths:

  1. Technical depth — produces well-architected, documented code that other engineers can build on without guidance
  2. Problem framing — asks the right questions early and identifies assumptions that would otherwise cause rework mid-sprint
  3. Reliability — commitments are consistently met; when something slips, there is an early flag

3 areas of improvement:

  1. Cross-team communication — technical decisions that affect other teams are sometimes made without consultation; building the habit of a quick check before committing to an approach would prevent downstream friction
  2. Code review tone — feedback is accurate but can read as curt; adding context for why a change matters would make reviews more useful for junior engineers
  3. Scope management — a tendency to expand scope while solving a problem; agreeing on boundaries upfront and flagging when the scope is growing would reduce unplanned work

Example 2 — Marketing manager

3 key strengths:

  1. Campaign execution — takes campaigns from brief to live with minimal oversight and consistently hits deadlines
  2. Data literacy — interprets analytics accurately and uses data to make decisions rather than to confirm existing preferences
  3. Stakeholder relationships — trusted by cross-functional partners; gets things done through relationships rather than authority

3 areas of improvement:

  1. Strategic input — tends to wait for direction rather than proposing the strategy; the skills and context are there to contribute earlier in the planning process
  2. Written communication — reports are thorough but long; developing a shorter executive summary format would make the work more accessible to senior stakeholders
  3. Delegation — tends to absorb execution rather than developing the team’s capacity; identifying which tasks could develop junior team members would improve both output and team growth

How constructive feedback connects to recognition

Constructive feedback and recognition are often treated as separate activities — recognition is for what went well, constructive feedback is for what needs to change. In practice, the most effective feedback culture combines both in the same rhythm.

The reason the combination matters: recognition without constructive feedback produces a culture where people feel appreciated but not developed. Constructive feedback without recognition produces a culture where people feel their contribution is only noticed when something goes wrong. Both alone are incomplete signals.

The organisations where feedback culture is strongest are the ones where:

Specific positive recognition happens frequently and publicly — through peer kudos, through named appreciation in meetings, through 1:1s that start with what went well before moving to what could improve.

Constructive feedback arrives in private, in a timely manner, from people with standing to give it — not as a public correction but as a genuine investment in the person’s development.

The ratio of positive to developmental feedback is roughly 3:1 or higher — not because negative feedback is being suppressed, but because there is genuinely more to appreciate than to correct in most people’s working week, and the appreciation is actually being named rather than assumed.

For teams using Karma in Slack or MS Teams, the peer recognition layer handles the positive side of this equation — making appreciation frequent, specific, and visible without requiring it to come only from managers. The anonymous feedback feature handles the candid developmental side — enabling honest pulse surveys and direct feedback without the social risk of named criticism. Together they create the conditions for a feedback culture where people feel genuinely seen, rather than only noticed when something goes wrong.

See how Karma supports feedback culture in Slack →


FAQ

What is constructive feedback? Constructive feedback is specific, actionable information about a behaviour or output that helps the recipient understand what to change and why — delivered in a way that preserves their dignity and their ability to act on it. It focuses on observable behaviours rather than character, explains the impact of the current approach, and points toward a concrete improvement. The word “constructive” means it builds toward something — a specific change, a clearer understanding — rather than simply criticising.

What is constructive criticism? Constructive criticism is feedback that identifies something that is not working and suggests how to improve it. It differs from simple criticism — which identifies a problem without offering direction — by including a clear indication of what a better approach would look like. Constructive criticism is most effective when it is specific about the behaviour, clear about the impact, honest about what is not working, and direct rather than wrapped in excessive qualification.

How do you give constructive feedback? Use the SBI framework: Situation (describe the specific context), Behaviour (describe exactly what was done or not done), Impact (explain the effect it had). Then suggest or invite a concrete alternative. Deliver constructive feedback privately rather than publicly, close to when the behaviour occurred, and in a tone that makes clear the purpose is to help rather than to criticise. Give the person space to respond — they may have context you don’t have.

What are areas of improvement? Areas of improvement are specific capabilities or behaviours that would make someone more effective in their role. In a performance context, they should be as specific as any constructive feedback — naming the exact skill or behaviour and explaining why improving it matters. “Communication” is not an area of improvement. “Proactive stakeholder updates when plans change” is. Areas of improvement should always be paired with a suggested path to development.

What is the difference between constructive feedback and negative feedback? Constructive feedback is developmental — it identifies what needs to change and points toward improvement. Negative feedback is evaluative — it assesses that something was wrong without necessarily offering a direction. In practice, all effective developmental feedback involves identifying something that is not working, making it inherently critical; the distinction is whether the feedback is delivered in a way that helps the person improve or simply communicates dissatisfaction. Constructive feedback is always specific, behavioural, impact-connected, and forward-looking.

How do you write areas of improvement in a performance review? Areas of improvement in a performance review should name the specific capability, describe a concrete instance where the gap was visible, explain the impact of the current approach, and suggest a path to improvement. For example: “Proactive communication when timelines change is an area for development. On three occasions this quarter, stakeholders received timeline updates through channels other than [Name] — which affected their confidence in the plan. Building the habit of a same-day message when anything changes would address this directly.”

Stas Kulesh
Stas Kulesh
Written by Stas Kulesh
LinkedIn
Founder of Karma and of Sliday, the Auckland design/dev shop behind it. I write most of this blog — posts on employee recognition, team culture, remote work, and the quiet behaviours that make teams perform. Off-keyboard: fretless guitar, Peep Show reruns, parenting.