Coachability, Feedback, and Humility Questions

Direct answer

I treat a comment as a pattern rather than a one-off once it recurs on multiple, independent reports, especially from more than one reader, not just repeated once by the same person. I fix it by changing the default template or process rather than editing the individual chart each time, and I make it stick by adding a check that catches the same class of problem before it ships again, not by just resolving to try harder next time.

Structured elaboration

The threshold. A single instance is feedback about one artifact; the same comment landing on report after report, especially from independent readers or across several weeks, is evidence about a default or a habit, not about that specific chart. Treating each occurrence as a fresh, isolated note misses that signal.

Diagnosing the actual gap. Get specific about what "unclear" means, since it's rarely literal; ask directly what confused them, missing axis labels, too many series on one chart, no stated takeaway, and confirm the diagnosis before changing anything.

Fix the system, not the instance. Once the gap is named, change the template or default so the next report inherits the fix automatically, rather than manually re-fixing each week's chart from memory.

Make it stick. Add a lightweight self-check or a second-reader step before a report ships, and track whether the same comment stops recurring over the following weeks. That's the actual evidence the fix worked, not just that you intended it to.

Worked example

For a few weeks in a row, different stakeholders left some version of "hard to tell what I'm supposed to take away from this chart" on my weekly report. The first time, I treated it as a one-off and added a clearer title to that week's chart. The second and third time, from two different people, I recognized the pattern and asked one of them directly what specifically felt unclear; it turned out I was defaulting to showing every metric on one combined chart, and readers couldn't tell which line mattered for the decision being discussed.

Instead of fixing that week's chart again, I changed the report template itself: a single headline chart per report focused on the specific metric relevant to that week's decision, with supporting detail moved to an appendix rather than crammed into the same view. I also added a required one-line "what this chart shows" caption to the template, so it wasn't something I had to remember to add manually. Over the following month, the same comment stopped showing up, which is what actually told me the fix had worked, not just that I'd made a change I felt good about.

Trade-offs and pitfalls

Treating each recurrence as a fresh, unrelated note and re-fixing the same instance every time means the underlying default never changes and the same comment keeps coming back. Overreacting to a single instance as if it's already a systemic pattern can trigger an unnecessary process change for something that was genuinely a one-off. And changing the template without verifying afterward that the comment actually stopped means you don't know whether the fix worked or you just got lucky one week.

Direct answer

"The numbers don't make sense" is a critique of correctness, not taste, so the first move is to resist the urge to explain or defend the report before you know what they actually mean. Ask specific clarifying questions to pin down the exact number and expectation, investigate methodically rather than guessing, then deliver the resolution in the stakeholder's language and document it so the same confusion does not resurface.

Structured elaboration

Clarify before touching anything. A vague complaint like this usually hides a specific mismatch. Ask: "Which number specifically, the total, the trend, a single row?" and "What were you expecting to see instead, and why?" Getting a concrete anchor (their mental model of what the number should be) turns a fuzzy complaint into a testable hypothesis.

Investigate systematically. Once you know the specific number and the expected value, check the usual sources of a real discrepancy: definitions (does "revenue" mean gross or net to them versus to the report), filters and time windows (is a date range off by a day due to timezone handling), duplication (a join that fans out rows), and staleness (a source table that has not refreshed). Reproduce the number from source data yourself rather than trusting the report's own logic, since the bug (if there is one) may be in the exact code that produced the number you are checking.

Deliver the resolution. If you find a real bug, say so plainly, show the corrected number, and explain in the stakeholder's terms what went wrong, not in pipeline internals they were never meant to parse. If the number turns out to be correct and the mismatch was a misunderstanding of definitions, explain that just as plainly and without condescension. Either way, close the loop with the same person who raised it.

Document the resolution. Add the clarified definition to a shared glossary or the report's own documentation, and if it was a genuine bug, note the root cause and the fix in a changelog. The goal is that the next person who asks "why does this number look off" finds an answer without repeating your investigation.

Worked example

Say a marketing lead flags that "the numbers don't make sense" on a weekly revenue dashboard, saying it looks too low. Clarifying question: "Are you comparing this week's total against last week's dashboard, or against a number from finance?" They say finance's number is noticeably higher. Investigating: pulling the raw transactions shows the dashboard is filtering by a timestamp that uses UTC, while finance's report uses local business-day cutoffs, so a chunk of Friday evening transactions is landing in the following week's bucket on the dashboard. That is a real, reproducible discrepancy, not a perception issue. The fix is to align the dashboard's day boundary with finance's convention. Delivering the resolution means telling the marketing lead, in plain terms, "the dashboard was cutting the day off a few hours early due to a timezone setting, it's now aligned with finance's cutoff, and this week's number reflects the fix." Documenting means adding a note to the dashboard's definition page: "day boundary = local business day, matches finance convention," so a future viewer does not raise the same question.

Trade-offs and pitfalls

Jumping straight to defending the report's logic before asking a clarifying question reads as defensive and often wastes time investigating the wrong thing. Assuming the stakeholder is simply wrong is just as risky as assuming they are right; treat the claim as a hypothesis to test either way. Explaining the fix in overly technical terms (join logic, pipeline stage names) leaves the stakeholder unable to judge whether the resolution actually addresses their concern. Skipping documentation is the most common failure: the fix holds until the next person hits the same ambiguity and the whole cycle repeats.

Direct answer

A comment like "make this more robust" gives me no way to know whether I'm done, so I turn it into questions that produce a checkable answer: what specific failure or scenario prompted the comment, what would count as evidence the concern is addressed, and is there a concrete case I should test against. The goal is to leave that exchange with something I could hand to someone else and have them verify, not just a vaguer version of the same feeling.

Structured elaboration

I ask a small set of questions aimed at converting vague language into something testable:

What specifically prompted this? "Was there a particular input, load, or failure case you had in mind, or is this a general concern?" This alone often resolves most of the ambiguity, since "robust" against malformed input is a completely different fix than "robust" against high concurrency.

What would satisfied look like? "If I add handling for X, would that address it, or is there more you're thinking of?" This turns a feeling into a testable claim, and lets the reviewer confirm or expand on it before I go build the wrong thing.

Is there a concrete example? "Do you have a specific case, or one you've hit before, that I should make sure this handles?" A concrete example is worth more than several more rounds of clarifying questions, since it's directly checkable.

Worked example

A pull-request comment says only "this needs improvement" with no further detail. I'd reply: "Happy to improve it, can you point me at what specifically prompted that, whether it's the error handling, the structure, or something else? And is there a particular case I should make sure it handles?" If the answer comes back as "the retry logic doesn't handle a timeout," that's now a concrete, testable requirement I can actually implement and verify, instead of guessing at what "improvement" meant and possibly missing the actual concern entirely.

Trade-offs and pitfalls

Asking too many clarifying questions at once, rather than the smallest set needed to get moving, can read as pushing the thinking work back onto the reviewer instead of engaging with it yourself. Assuming you know what "robust" or "improvement" meant, and guessing rather than asking, risks spending real effort solving the wrong problem and having to redo it. And once you do get a concrete answer, treating it as the only thing that ever needed fixing (rather than one instance of a possibly broader pattern) can mean the same vague comment resurfaces on the next piece of work.

Direct answer

The clearest signal is whether the feedback points at something checkable: a specific claim about the work that I could verify or disprove with evidence, versus a comment that's really just describing the reviewer's own taste. A second signal, one I've learned to distrust on its own, is how much the comment stings; sharp or blunt delivery feels like a bigger deal than a mild-sounding one, but sting is about tone, not substance, and plenty of substantive critique is delivered gently. When it's substantive, I act on it directly; when it's preference, I still take it seriously as one input, but I don't treat it as a required change.

Structured elaboration

The core signals. Substantive feedback usually points at a consequence: this will break under a specific condition, this number doesn't match what we'd expect, this choice conflicts with a constraint we already agreed on. Preference feedback usually points at how something feels without a checkable claim attached: "I'd have done it differently," "this doesn't feel right to me," with nothing you could go verify. A useful test is to ask yourself: if I ran an experiment, checked a number, or asked a third person, could this comment turn out to be simply wrong? Substantive feedback can fail that test; pure preference generally can't, because there's no external fact being claimed.

Why the sting test is unreliable on its own. Feedback that lands hardest emotionally is not necessarily the most substantive; a harshly worded comment can be pure opinion, and a mildly worded one can be pointing at a genuine, checkable flaw. Using emotional intensity as your filter means you'll sometimes chase down a stylistic complaint because it stung, while quietly dismissing a calmly delivered but substantive concern.

What changes based on the distinction. For substantive feedback, I go verify the claim (rerun the analysis, check the edge case, re-read the constraint) and act on what I find, regardless of how it was delivered. For preference feedback, I still note it, since patterns across multiple people's preferences can eventually become a real signal, but I don't treat one person's taste as mandatory, and I'll say so directly rather than either silently complying or silently ignoring it.

Worked example

Three quick illustrations across different work: a colleague says a chart's y-axis should start at zero instead of the current range, because starting elsewhere exaggerates the visual difference. That's checkable: does the truncated axis actually misrepresent the size of the effect? If yes, it's substantive and worth fixing regardless of preference. Separately, on a business intelligence (BI) dashboard, a stakeholder says they'd prefer more chart types instead of mostly tables; there's no checkable claim there, it's a stated preference, worth noting but not obligatory unless it recurs across multiple stakeholders. On a proposed system architecture, a reviewer says a particular service boundary "feels wrong" with no further explanation; I'd treat that as underspecified rather than automatically substantive or automatically preference, and ask what specifically prompted the reaction, since it might be pointing at a real coupling problem they haven't fully articulated yet.

Trade-offs and pitfalls

Dismissing feedback as "just preference" is an easy way to avoid genuinely uncomfortable, valid criticism, so the test has to be applied honestly, not used as a shield. On the other side, treating every comment as substantive because you can't immediately disprove it leads to chasing every stylistic complaint as if it were a bug report, which is exhausting and doesn't actually improve the work. And an unexplained "feels wrong" comment shouldn't automatically be filed as preference just because it wasn't stated as a checkable claim; ask before you categorize it.

Direct answer

"More strategic" tells me my manager wants something different from what exists, but not what that something is, so I ask questions aimed at recovering the missing pieces: who's going to use it and for what decision, what "strategic" is implicitly being contrasted against, and what a good version would let someone do that the current one doesn't. Each question matters because without an answer to it, I'd be guessing at a target instead of building toward one.

Structured elaboration

Who is this actually for, and what decision are they making with it? A dashboard aimed at an executive making a quarterly resourcing call needs different content than one aimed at a team lead tracking weekly progress. "Strategic" almost always implicitly means "more useful to a specific higher-stakes audience," so naming that audience turns a vague adjective into a concrete design target.

What is "strategic" being contrasted against? Often this means the current version is read as too operational or too granular, day-to-day numbers without the "so what." Asking directly, "is the concern that this is too in-the-weeds, or that it's missing a business-level takeaway?" separates two very different fixes: rolling metrics up to a higher level of aggregation, versus adding interpretation and recommendation on top of metrics that are already at the right level.

What decision or action should this enable that it doesn't today? This question matters because it grounds "strategic" in something testable: if the redesigned dashboard still can't help someone answer the specific question they had in mind, the redesign hasn't actually solved the problem, regardless of how much more polished or high-level it looks.

Is there a comparable example of what "strategic" looks like to them? If my manager has seen a dashboard, report, or deck elsewhere that hit the mark, asking for that reference gives a concrete target faster than iterating blind.

Worked example

My manager says a weekly metrics dashboard needs to "feel more strategic" before it goes to leadership. I'd ask: "when leadership looks at this, what decision are they trying to make, resourcing, prioritization, something else?" and "is the issue that it's too granular, or that it's missing interpretation of what the numbers mean?" The answers might reveal that leadership doesn't need the daily breakdown at all, they need a rolled-up trend with one or two sentences of what's driving it and what it implies for next quarter. That's a concrete brief I can actually build against, instead of guessing at what "strategic" was supposed to mean and redesigning the wrong thing.

Trade-offs and pitfalls

Asking too many questions before doing any work can read as stalling, especially if the manager expected you to just take a first pass and iterate. Assuming "strategic" means "more polished visually," without checking, is a common miss, since the actual gap is usually about content and framing, not aesthetics. And building toward an assumed target without confirming it, then discovering after real effort that it wasn't what they meant, costs far more time than the clarifying questions would have.