Giving and Receiving Feedback Questions

Direct answer

I'd start with what is genuinely good (the numbers are right, which is the hardest part to teach), name the problem as the audience's experience, show one slide fixed rather than describe it in the abstract, and then ask for just two changes first: (1) one message per slide, stated as a title that says the takeaway, and (2) one chart or table per slide, with everything else removed or moved to an appendix.

What I would actually say

"Thanks for sending this. Your numbers check out against the source, and that's the part people usually get wrong, so well done. When I read it as someone who wasn't in your analysis, though, I had to hunt for the point on slides 4, 5 and 8. Each has three charts and a paragraph, and I couldn't tell which one mattered. Here's one slide redone as an example (I'll share it). I'd like you to try two changes first. One: make each slide title the takeaway, like 'Churn rose in the new-plan cohort', instead of 'Churn analysis'. Two: keep one chart per slide and move the rest to an appendix. Do those two on the whole deck, then send it back and we'll look at colors and wording after. How does that sound? Anything you were trying to show that I've missed?"

Why this structure

• Specific praise first is information, not cushioning; it tells them what to keep.
• Audience impact ("I had to hunt") is observable and not about ability.
• A worked example teaches faster than a list of rules for a junior.
• Only two changes because a long list overwhelms a newcomer and they fix the cheap items (fonts) instead of the important ones. Colors, chart types, and spacing come in round two.
• Ask for their intent, since the clutter may come from fear of leaving something out.

Pitfalls

Do not rewrite the deck for them, do not say "it's messy" with no example, and do not hand over eight changes at once.

Direct answer

Here is a story I would tell. A stakeholder challenged a forecast I presented. In the moment I stayed curious rather than defensive: I restated the concern, asked for the specifics, and committed to a date to come back with an answer. I followed up with evidence and credited them, and the result was a changed way of working with that group.

Situation and task

(An illustrative story shape.) I was a data scientist presenting a customer-churn forecast (a prediction of how many customers will leave) to finance and sales leaders. A finance director said, "This number looks wrong. It ignores last quarter's pricing change." My task was to keep the room's trust and find out whether she was right.

What I did in the moment

• Did not defend or explain the model at length. I said: "Let me make sure I understand. You expect the pricing change to affect the group of customers I used as the baseline (the past behavior my forecast extends)?"
• Asked two questions: which accounts were affected, and when did the change take effect?
• Admitted what I did not know: "I'm not sure the model captures that. I'll check and send you an answer by end of day tomorrow."
• Wrote down the concern in front of her.

Follow-up

• I re-ran the forecast with a flag (a yes/no column marking which accounts were on the new pricing), so those accounts could get their own churn rate instead of the average. Illustrative numbers: of 800 accounts, 120 were on the new pricing. The original forecast applied 3% churn to everyone: 800 x 3% = 24 accounts. Early data showed the new-price accounts leaving at about 8%, so the revised forecast was 120 x 8% = 9.6 plus 680 x 3% = 20.4, which is 30 accounts, or 3.75%. The projection rose by about a quarter, so her critique was largely right.
• I sent a short note: what I checked, the before and after, what changed in the assumptions, and a thanks that named her contribution.
• I asked her to review the revised assumptions before sharing more widely.

Result

• The updated forecast became the basis for planning, and the finance team trusted the numbers more because the correction was visible and fast. (Illustrative: the story shape matters more than the figures.)
• Process changes: I added an assumptions page at the start of every stakeholder readout, sent a draft to finance a few days ahead, and added a checklist of recent business events (pricing, launches, policy changes) to compare against before presenting. The assumptions page lists, for example: "Churn rate by customer segment: 3% (last four quarters)", "Excludes: accounts that signed up in the last 30 days", "Not modeled: pricing changes after 1 March". The checklist asks: "Any price or packaging change in the last two quarters? Any product launch or retirement? Any policy or contract change?" I would not claim exact accuracy gains from this; the clearest outcome was fewer surprises in meetings.

What I would do differently

Share the draft with finance before the meeting, so the critique arrives in review, not in the room.

Trade-offs and pitfalls

• Agreeing instantly with every criticism can be as unhelpful as defending. If the critique is wrong, say so with evidence, politely and in follow-up.
• Do not promise a date you cannot meet.
• Make the stakeholder visibly part of the fix.

The message (about 100 words)

Context: the dashboard tracks churn, the share of customers who stopped using the product.

Hi Priya, I opened the churn dashboard after Tuesday's review, where two people read the headline number differently. Two things caused it: the "Active" label does not say it means a login in the last 30 days, and there is no region or plan filter, so each team read the global figure as its own. The meeting then spent its time on what the number meant instead of the decision. Could we add a one-line definition under each label and the two filters? I can pair for 30 minutes this week and test it on someone who has not seen it. The charts themselves are clear.

Why it is built this way

• It follows SBI (Situation, Behavior, Impact, a model from the Center for Creative Leadership). Mapped onto the message: Situation = "after Tuesday's review"; Behavior = "the 'Active' label does not say it means a login in the last 30 days, and there is no region or plan filter"; Impact = "the meeting spent its time on what the number meant instead of the decision".
• It critiques the dashboard, not the person. The sentence about clear charts is true and specific, not a compliment sandwich.
• It makes one concrete ask (definitions plus two filters) and offers help with a time limit, so it is easy to say yes to.
• It gives evidence of misreading (two people, one number), which beats "stakeholders are confused" because the peer can check it.

The same method on a README for a model-serving container

A container is a packaged way to run a program with everything it needs, so a teammate can start it with one command. A model-serving container does that for a trained model that answers requests. Environment variables are named settings (such as a database address) that the program reads when it starts, and the Dockerfile is the recipe that builds the container image (the packaged template a container is started from).

Feedback note: "Your README (the file explaining how to run the container) starts with the architecture. When I tried to start it, I could not find the command to run it or which environment variables it needs, so I had to read the Dockerfile. Could the first screen be: what it does, the exact run command, required environment variables, and how to check it is healthy? A new teammate could then run it in five minutes, and we could drop the setup questions in chat." For a junior's README, add one comment on each of the three things you want: purpose, a reproducible run command, and the reason behind non-obvious settings.

The same method on an exploratory notebook with no conclusions

Feedback note: "In the churn notebook I found the plots, but I could not tell what you concluded or what you tested and dropped. Could you add a short summary cell at the top: the question, the three findings, the data and date range used, and what you would do next? Anyone opening it later could then use it without rerunning all of it."

Pitfall to avoid

A message that says "labels are confusing" with no example gives the peer nothing to fix and invites defensiveness.

Direct answer

My default is asynchronous (written, on the pull request (PR), doc, or ticket) for specific, checkable feedback, because it is precise, linkable and gives the author time to think. I switch to live when the feedback is about direction or architecture, when the topic is ambiguous or emotionally loaded, or when an async thread has gone about two rounds of reply and counter-reply without converging. I make feedback get acted on by turning it into items with an owner and a date, writing the outcome of any live conversation back to the written record, and checking at a set point.

Choosing the channel

Making sure it is acted on

• Each item gets an owner, a due date, and a place (ticket or PR checklist), and I ask for a one-line reply.
• After a live review, I post the decisions and action items the same day; otherwise the conversation did not happen as far as absent teammates are concerned.
• At the next checkpoint I look at the list, not at my memory.

Reviewing SQL, ETL and dashboards

(ETL means extract, transform, load: the jobs that move and reshape data.) I use criteria, not taste, and put them in the review checklist:

• SQL: the output grain (what one row represents, for example one row per order), join correctness, row counts reconciled to the source, and readable formatting, enforced by a linter (a tool that automatically flags style problems) such as SQLFluff.
• ETL: safe to re-run without duplicating rows, automated data tests (for example the dbt tool's not_null check, which fails if a column has blanks, and unique check, which fails if a key repeats), and clear failure alerts.
• Dashboards: metric definitions written down, filters that behave as labelled, and the audience's question answered on the first screen.

A written review comment on a join might read: "This join to customers can return two rows per order when a customer has two addresses, so revenue is double counted. Row count before the join is 10,000 and after is 10,400. Please join on the primary address only, or aggregate first. Blocking, because the totals are wrong."

Tracking implementation uses the same method: checklist items in the PR or ticket, closed explicitly.

Example: a design review that changed a design, and the pushback

In a design review I flagged that a new feature chained three services synchronously (each call waits for the previous one to finish, so one slow or failed service stalls the whole request). If each service is up 99.9% of the time ("99.9% available"), the request only succeeds when all three are up, so the chain is about 99.7%:

0.999 x 0.999 x 0.999 = 0.997

That is roughly 26 hours of failure a year instead of 9, so one risky hop becomes everyone's outage. The owner pushed back: a queue (a buffer that lets work wait and be processed later, so the caller does not block) would cost two weeks. I asked what the real deadline was, separated must-fix from suggestions, and proposed a smaller step: make only one hop asynchronous, the one with the worst incident history (the weakest link in practice, even though the 99.9% figure above is a simplifying assumption of equal services), meaning it runs through the queue instead of making the caller wait. That leaves two synchronous services: 0.999 x 0.999 = 0.998, about 17.5 hours of failure a year instead of about 26. We agreed, and I wrote a short decision note with a trigger to revisit if volume doubled.

Pitfalls

• Two rounds of reply and counter-reply in a pull request (PR) thread without convergence, and certainly ten messages, is a signal to get on a call.
• A call without a written summary leaves the feedback unowned.

Direct answer

I would leave one written comment that starts with what works (the results are correct), orders my suggestions by impact (performance first, then maintainability, then style), explains the reason for each, and offers to go through it together. In the follow-up conversation I would ask about data volume and how often the query runs, offer to read the query plan together, and agree what to change now versus later.

Terms: a CTE (common table expression) is a named temporary result defined with WITH. A query plan is the database's step-by-step description of how it will run the query, shown with EXPLAIN. An index is a sorted lookup structure on a column, like a book's index, that lets the database jump to matching rows instead of reading the whole table. SELECT * means "return every column of the table".

The written review comment (draft)

Thanks for this: I ran it against the sample month and the totals match the finance report, so the logic looks right. A few suggestions, in order of importance.

1. Should fix if the plan shows a full scan on a large table; otherwise Consider (performance). WHERE DATE(created_at) = '2026-09-01' wraps the column in a function, which in most databases stops an index on created_at from being used. Could we write created_at >= '2026-09-01' AND created_at < '2026-09-02'? Same result, index-friendly.
2. Should fix (maintainability). The four nested CTEs make the logic hard to follow, and each one reads the previous. Could we flatten into sequential named steps (orders_in_day, orders_with_customer, daily_totals) with a one-line comment each?
3. Consider. Select only the columns we use instead of SELECT *, so later schema changes do not break it.
4. Nit. Keyword capitalisation is mixed.

Happy to pair for 20 minutes on the plan if you'd like.

How I prioritise

1. Wrong results (none here).
2. Cost that grows with data (the function on the column).
3. Understandability for the next maintainer (nested CTEs).
4. Style.

Check on the rewrite

The two filters return the same rows. I ran both on a small test table of three orders:

For 2026-09-01 both filters return orders 1 and 2, total 20.00 + 35.00 = 55.00. The 23:30 order shows the range version keeps late-evening rows. The runnable check (SQLite, so date() stands in for DATE()):

create table orders(id int, customer text, created_at text, amount real);
insert into orders values (1,'A','2026-09-01 09:00:00',20),(2,'B','2026-09-01 23:30:00',35),(3,'A','2026-09-02 08:00:00',15);
select id, amount from orders where date(created_at) = '2026-09-01' order by id;
select id, amount from orders
 where created_at >= '2026-09-01' and created_at < '2026-09-02' order by id;

Both queries print the rows for ids 1 and 2. The index benefit depends on the database and the table size, which is why I ask for the plan rather than asserting a speed-up. Because I do not yet know the table size, I label item 1 "Should fix" only if the plan shows a full scan on a large table; on a small daily job it drops to "Consider".

Follow-up conversation

• Ask: how many rows is the table, and how often does this run? A daily job on 10,000 rows may not need tuning today.
• Read the EXPLAIN output together: this teaches the skill, not only the fix. In PostgreSQL, a line such as "Seq Scan on orders" means every row is read; "Index Scan" means the index is used (variants such as "Index Only Scan" and "Bitmap Heap Scan" also use an index).
• Agree: apply items 1 and 2 now; item 3 if time allows.
• Offer ongoing support: share a short style guide or example of a flat CTE layout.

Trade-offs and pitfalls

• Rewriting their query in the review takes away their ownership; suggest, explain, offer.
• Fixating on performance when the query runs once a day wastes their time; ask about usage before pushing.
• Calling a correct query "bad" discourages; start with what is right.