Giving and Receiving Feedback Questions

Situation: A senior ML engineer on my team had been using a complex ensemble of bespoke feature engineering and an older tree-based model for a recommendation system. Our experiments and infra constraints suggested a simpler transformer-based ranking model would improve latency and maintainability, but they were resistant to changing their approach.

Task: I needed to give constructive, actionable feedback that respected their expertise, reduced defensiveness, and led to measurable experimentation toward a better solution.

Action:

• Prepare: I reviewed the code, recent experiment logs, and evaluation metrics. I prepared a short comparison (metrics, latency, infra cost, reproducibility) and identified concrete failure modes of the current approach with examples. I planned a private, time-boxed 1:1 and an agenda: share observations, ask for their perspective, propose experiments, align on criteria for success.
• Language & tone: I used curiosity-first, nonjudgmental language: “I noticed…”, “Can you help me understand…”, “What constraints led you to choose…?” Then I shifted to impact-focused statements: “Because A and B, our inference latency is X and recall is Y; that leads to Z business impact.” I suggested concrete alternatives as experiments, not mandates: “Would you be open to running a controlled A/B comparing the ensemble to a lightweight transformer on a held-out slice?”
• Actionable requests: I proposed a clear experiment plan with success criteria (metric lift, latency threshold, infra cost), timeline (2 sprints), and required resources. I volunteered to pair on implementation and to help with baseline reproducibility.
• Follow-up: We documented the experiment in the team tracker, scheduled short weekly syncs to unblock issues, and agreed on decision rules (if metric improves by ≥1% and latency < target, proceed to rollout). After results, I gave balanced feedback highlighting positives and next steps, and suggested knowledge-sharing sessions.

Result: The collaborative, evidence-focused approach reduced defensiveness, produced two quick experiments within the agreed timeframe, and led to a simpler model that met latency and accuracy goals. The senior engineer retained ownership of the work and later advocated for the new approach.

What I learned: For senior peers, respect and data matter most—ask questions, suggest experiments, provide resources, and set clear, mutually agreed decision criteria to drive adoption.

Situation: On a cross-functional project I was part of, a colleague delivered multiple model releases whose documentation omitted input/output schemas, pre/post-processing steps, and expected failure modes. Integrations kept breaking in downstream services, causing two rollbacks and wasted engineering time that sprint.

Task: As the AI engineer responsible for end-to-end reliability, I needed to give constructive feedback so the documentation improved, integrations stabilized, and the relationship with my colleague stayed collaborative.

Action:

• I scheduled a one-on-one in a private setting and started by acknowledging their hard work and the model’s performance strengths to set a positive tone.
• I showed specific, reproducible examples of the integration bugs (log snippets, failing inputs, and timestamps) and explained how missing details in the docs caused each failure—keeping the focus on facts, not personalities.
• I proposed concrete, low-effort remediation: a documentation checklist (input/output schema, sample payloads, latency/throughput expectations, preprocessing code snippets, known edge cases), and a small doc template stored with the model repo.
• I offered help: paired session to fill in one model’s docs, and to add automated model-contract tests in CI that validate schema and basic inference behavior.
• We agreed on ownership: they’d update the docs for current models within one week; I’d help add 2 CI tests and review the first doc update.

Result: Within two sprints integration failures tied to documentation dropped by ~85%, average time-to-integrate decreased from 3 days to 1 day, and my colleague adopted the template for future releases. The interaction preserved trust: they appreciated the concrete examples and hands-on help. I learned that pairing feedback with actionable templates and automation accelerates behavioral change and reduces friction across teams.