Giving and Receiving Feedback Questions

Situation: Our sales leadership team reluctantly used a weekly Power BI dashboard I owned; they told me adoption was low during a quarterly review—people found the default view overwhelming and couldn't quickly find territory-level performance.

Task: My goal was to make a modest, user-centered change that increased regular use without a full redesign.

Action:

• I ran a quick 10-minute contextual interview with three sales managers to clarify pain points (too many KPIs, unclear filters).
• Implemented two small changes in one sprint: (1) added a compact “Top-line / Territory” toggle that defaults to territory view, (2) moved the most-used KPI (sales vs. quota) into a fixed header with color-coded status and tooltips, and (3) added a persistent search box for rep names.
• Published the update and pinned a one-slide “how to” and 30‑second demo in our team channel.

Result / Validation:

• Tracked usage before/after: weekly active users rose from 14 to 28 (+100%) in four weeks.
• Average session duration fell 35% (from 4:20 to 2:50) while task completion (filter to territory + find rep) success in a quick usability test improved from 40% to 90%.
• Qualitative feedback: managers reported they could get answers in under a minute and used dashboard screenshots in weekly standups.

Learning:

• Small, targeted UI changes aligned to real user tasks can drive adoption faster than broad feature additions.
• Validate by combining simple metrics (active users, session time) with short usability checks to ensure faster sessions reflect efficiency, not disengagement.
• When requirements are uncertain, prioritize observed user tasks, prototype quickly, and iterate with lightweight feedback loops.

Code review comment (short):
Thanks — this returns correct results and is clearly well thought through. A few maintenance and performance issues I’d like us to address: 1) break the query into named CTEs with comments, 2) avoid SELECT * and push filters before joins, 3) add indexes or rewrite the heavy aggregation, and 4) add unit test cases/expected-row counts. I’ve annotated specific lines with suggested refactors and a small rewritten CTE for the slow join. Happy to pair on this.

Talking points for the follow-up conversation:

• Praise the correct logic and clarify the business intent the query fulfills.
• Walk through the largest performance hotspot (explain plan summary).
• Show a small, readable refactor (CTEs + column lists) and benchmark the runtime/memory.
• Discuss maintainability: naming, comments, tests, and ownership.
• Agree on acceptance criteria for changes (no behavior change, runtime improvement target).
• Offer pairing/mentorship and next steps.

Prioritization of suggested changes:

1. Safety fixes that could change results — add tests and full-column checks (high, must do).
2. Performance hotspots from the explain plan — push filters, rewrite joins/aggregations (high).
3. Small readability and maintainability improvements — CTEs, explicit columns, comments (medium).
4. Schema/index suggestions — collaborate with DBAs and schedule if needed (low→medium).
5. Add CI tests and documentation for future edits (medium).

How I’d give this feedback to preserve psychological safety:

• Start with specific positive recognition of correctness & impact.
• Use curiosity-first language: “I’m curious about this join — can you walk me through the intent?”
• Focus on the code and system, not the person; use “we/our” for ownership of improvements.
• Offer concrete help (pair programming, benchmarking) and timeboxed changes.
• Agree on measurable goals and celebrate when improvements land.
• Close by asking for their perspective and agreeing on next steps so they retain agency.

1. Situation: In yesterday’s strategy review presentation with the Go-to-Market leads,
   Behavior: your slide deck included all the correct charts and numbers but had dense tables, small fonts and many colors on each slide,
   Impact: the audience spent time deciphering visuals instead of discussing recommendations, so we missed a chance to align on priorities.

2. Situation: During the 10-minute walkthrough you led,
   Behavior: you explained detailed data transformations on-screen instead of highlighting key insights,
   Impact: stakeholders were unclear on the main takeaways and asked follow-up questions that extended the meeting.

3. Situation: For the executive summary slide,
   Behavior: you placed multiple KPI charts without an ordering that supports a narrative,
   Impact: executives couldn’t quickly interpret performance trends and asked for a separate one-page summary.

4. Situation: In the appendix,
   Behavior: you included raw tables and cross-tabs inline rather than as downloadable artifacts,
   Impact: it distracted non-technical readers and added cognitive load during the discussion.

5. Situation: While answering questions,
   Behavior: you toggled between many slides to find supporting evidence,
   Impact: this broke the flow and reduced confidence in the recommendations.

Two immediate, concrete improvements:

• Simplify each slide to one clear message: add a single headline (insight + recommendation), one visual that supports it, and remove extraneous charts or colors.
• Increase visual clarity: use larger fonts (>=18pt), consistent color palette for categories, and move raw tables to an appendix or link a downloadable CSV so the main story stays focused.