Criticism is useful when it identifies a shortcoming and helps someone improve. In a development team, constructive criticism can reveal problems a developer or lead might not notice alone. Its purpose is growth, not blame; delivered carelessly, negative feedback can damage confidence or motivation. section 6.2.2 section 10.2.2
Before and during a feedback conversation:
- Decide whether the issue needs raising. A different way of writing code is not necessarily a problem if the result is good enough. section 10.5.2
- Arrange a conversation without sending an alarming, vague message. Start with specific recognition, state the concern briefly, and leave room for a response. section 10.5.2
- Describe the behavior and its effect, then suggest a way forward. Use statements such as “I noticed” rather than an accusation; listen even if the developer disagrees. section 10.2.2 section 10.2.3
- Offer help and follow up. Guidance, learning resources, or a suitable assignment can support improvement without taking over and redoing the person’s work. section 10.2.2 section 10.5.2
Make the next step visible
“Your presentation was well-organized and clear; adding more visuals could help illustrate your points” identifies both a strength and a specific change. Similarly, if unclear sprint updates caused confusion about requirements, suggest regular updates and more active participation in team discussions rather than simply calling the person a poor communicator. section 6.2.2 section 10.2.3
Receiving criticism takes practice too. Listen without treating it as an attack, consider what it reveals, and make a change where warranted. A lead who accepts feedback models that openness for the team. Positive feedback has its own job: recognize specific achievements and encourage continued growth, not merely soften a difficult message. section 6.2.2 section 10.2.1
