Feedback is information about what is working, what needs to change, and why. For a lead developer, it is a two-way practice: give team members useful guidance, and invite developers, managers, and stakeholders to challenge your own approach. Without feedback, people can struggle to see how to improve. section 10.2 section 3.4.1
When giving feedback to a person:
- Be specific and genuine about strengths. Name the accomplishment or skill rather than stopping at “Great job,” and consider what opportunity could help the person grow further. section 10.2.1
- For an improvement, describe a concrete concern and offer a path forward. Listen to the person’s response instead of treating feedback as a verdict. section 9.1 section 10.5.2
- Decide whether the issue warrants a conversation at all. A different approach is not necessarily a problem if the work is good enough. section 10.5.2
- Make time for a private, minimally distracting conversation when the issue needs discussion. Set an objective, adapt to the person’s communication style, and avoid rushing; bluntness can land differently across cultures. section 10.2.3 section 10.2
A deadline conversation
If a developer repeatedly misses project deadlines, set out to understand the cause together and make a plan for improving time management. Do not simply take over their work: guidance gives them a chance to make the needed changes and develop their skills. section 10.2.3 section 10.5.4
Positive feedback and constructive criticism serve different purposes. Praise reinforces a specific contribution; constructive criticism identifies an area to improve without demeaning the person. One option for a difficult discussion is the Sandwich technique, which places criticism between two pieces of positive feedback. Whatever approach you choose, keep the concern clear and give the other person room to respond. section 10.2.1 section 9.1 section 10.2.3 section 10.5.2
Receiving feedback calls for the same care. Ask colleagues, team members, and managers for honest observations; listen to junior developers and nondevelopers as well as experienced peers. Negative feedback may be uncomfortable, but treating it as information rather than a personal attack can reveal a weakness you had not noticed. A lead who listens and changes course also models that behavior for the team. section 3.1.2 section 6.2.3 section 6.2.2
Feedback also improves work beyond individual performance. Ask documentation readers whether instructions are clear and whether they found what they needed; developers, testers, project managers, and end users may notice different problems. Consider comments that do not directly apply to the document: they may point to a wider user-experience issue. Gather process feedback through retrospectives, and use stakeholder and customer perspectives when refining development decisions and products. The useful final step is to act on what you learn, then ask again. section 5.4.2 section 6.1.2 section 6.2 section 6.0
