Giving and Receiving Feedback Questions

Situation: I manage a roadmap where a senior engineer repeatedly missed integrations and delivered late fixes, causing downstream QA and partner teams to re-plan and delaying releases.

Task: I needed to deliver direct, constructive feedback to stop the pattern while preserving the relationship and keeping product timelines on track.

Action — Preparation:

• Gather facts: dates, missed commitments, impact on schedule, customers, and teams (quantify delays and rework hours).
• Collect examples across multiple sprints to show pattern, not a one-off.
• Anticipate reactions and prepare support: alternative resourcing, scope reduction, or clearer acceptance criteria.
• Choose a private, uninterrupted 1:1 slot and invite their manager if escalation may be needed later; start solo to attempt direct resolution.

Script/Structure (use direct, empathetic framework):

1. Open: “Thanks for meeting. I value your contributions; I want to discuss something important that affects the team.”
2. Observe (facts): “In the last three integrations (dates), the merges were late or required emergency fixes, which caused X hours of QA rework and a one-week slip.”
3. Impact: “This delayed launch, strained QA, and hurt partner trust.”
4. Ask/Listen: “Can you help me understand what happened?” (pause, listen)
5. Collaborate: “Given what you shared, here are options: adjust scope, add earlier code-freeze checkpoints, pair with an engineer for integration, or reassign parts. Which will work?”
6. Agreement: “Let’s agree on specific commitments and checkpoints.”
7. Next steps: “I’ll share this summary and check in on [dates].”

Manager involvement:

• If immediate mitigation required, copy the manager on a short mitigation plan.
• If behavior persists after the agreed timeline, escalate to manager with documented facts and prior 1:1 notes; involve them to set development plan or workload changes.

Follow-up actions & timeline:

• Within 24 hours: send written summary of meeting, agreed actions, and checkpoints.
• Week 1: implement immediate mitigation (reduce scope or pair programming for next integration).
• Weeks 2–4: weekly 15-minute check-ins to track integration readiness and blockers.
• 30 days: review outcome against metrics (on-time integrations, number of hotfixes, QA rework hours). If improved, acknowledge publicly; if not, involve manager to define a performance improvement plan with clear expectations and timeline (60–90 days).

Result/Outcome expectation:

• Clear, measurable improvement in on-time integrations and fewer late fixes, preserved relationship, and reduced downstream risk. This approach balances accountability, support, and escalation only when necessary.

Situation: At my last company we were three weeks into redesigning the onboarding flow. Our lead designer delivered a high-fidelity screen set that looked beautiful but increased cognitive load and added two extra steps; engineers flagged complexity and stakeholders worried about conversion impact.

Task: As PM, I needed to give constructive feedback to the designer so we could balance clarity, engineering effort, and conversion goals without damaging our working relationship.

Action:

• Preparation: I reviewed user research, analytics (drop-off rates at onboarding), and the design files. I sketched a simpler alternative and prepared examples of where the new screens deviated from our hypothesis and metrics.
• Structure & language: I used a private one-on-one, started with appreciation (“This is visually strong and addresses brand consistency”), then moved to impact-based language (“I’m concerned these extra steps could raise drop-off; our baseline shows sensitivity at each added step”). I framed feedback as collaboration: “Can we iterate to keep this visual polish but reduce steps? Here’s a sketched option and two success criteria: ≤10% dev effort increase, no worse conversion in A/B test.”
• I asked open questions (“What user problem were you prioritizing here?”) and invited alternatives, keeping the conversation two-way and non-judgmental.

Result: The designer agreed to a revised flow that preserved key visual elements but consolidated inputs into one screen. Engineering estimated a 20% lower implementation effort. We A/B tested the revised flow and saw neutral-to-positive conversion with higher NPS for clarity. The designer later said the collaborative, impact-focused feedback felt respectful and made future iterations easier. Learned: anchor feedback in data, be specific about desired outcomes, and propose alternatives.

Preparation:
I gather concrete examples (code reviews, missed SLAs, scope gaps), objective metrics (cycle time, bug rate, delivery variance) and feedback from peers/stakeholders. I clarify the performance gap I want to address, decide desired outcomes, and prepare a few coaching questions. I book a private 1:1 slot, set a collaborative tone, and ensure no surprises by giving a short agenda ahead.

Structure of the conversation:

• Open with intent and psychological safety: “I want to help you succeed—can we talk about a few observations?”
• Facts first: present 2–3 specific, time-bound examples and supporting metrics.
• Impact: explain product/business/team consequences (delays, customer confusion).
• Listen: ask for their perspective, blockers, personal context.
• Co-create plan: agree on 2–3 measurable goals (SMART), required support (mentorship, training, scope change), and quick wins to rebuild confidence.
• Close with affirmation: reiterate belief in their ability and restate next steps.

Follow-up to ensure improvement and morale:
Set short cadence check-ins (weekly for 4–6 weeks), track metrics and qualitative feedback, adjust plan as needed, and celebrate progress publicly and privately. If no improvement, document conversations and align with HR for formal steps. Throughout, balance accountability with recognition, provide resources, and keep communication empathetic and solution-focused so the engineer feels coached rather than punished.