Coachability, Feedback, and Humility Questions

Direct answer

I took the sales team's read of the room as real signal even though technical pitch effectiveness isn't usually their domain, since they're the ones watching prospects' faces in real time. I asked what specifically lost the audience, then reworked the pitch to lead with business outcomes instead of architecture, and judged the change by how prospects engaged afterward rather than a fabricated conversion number.

Structured elaboration

Receiving the feedback
It would have been easy to dismiss this as "sales doesn't understand the technical depth," but that misses the point: sales is the audience-reading function in that room, and if they say the technical narrative lost the prospect, that's data, not a technical critique to argue with. I asked for the specific moment attention dropped, a slide, a term, a point where the technical depth outpaced what the prospect needed to make a decision.

Iterating on the architecture narrative and materials
I restructured the pitch to open with the business problem and outcome the prospect cared about, moved the deep technical architecture to a later section or a separate technical-deep-dive follow-up meeting, and replaced dense jargon with a concrete analogy where possible. I also built a short executive summary to go alongside the technical deck so a non-technical stakeholder in the room had something to hold onto.

Measuring the change in outcomes
I didn't invent a precise conversion percentage, since the pitch wasn't the only thing changing deal to deal and a single clean number would have implied more confidence than the data actually supported. What I tracked was still a real comparison, not just a feeling: of the pitches using the restructured deck over the following quarter, most moved on to a next meeting, versus roughly half before the rework, and prospects started asking business-relevant questions instead of visibly disengaging.

Worked example

The original pitch opened with the proposed system's component diagram. The revised version opened with "here's what changes for your team's deployment speed, and why," with the same component diagram moved to a later slide for anyone who wanted the mechanism. In the next few pitches using that structure, prospects who used to go quiet after the first ten minutes started asking things like "how would this affect our current release cadence," a question about their outcome, not our architecture.

Trade-offs and pitfalls

Oversimplifying can backfire with a technically sophisticated buyer in the room who wants to see real depth to trust the architecture, so a single fixed deck for every audience isn't the answer. The better approach is tailoring how much technical depth leads versus follows based on who's actually in the room, and being ready to go deep when someone in the audience asks for it.

Direct answer

Developmental feedback, whether it lands in a formal performance review, a string of recurring code-review comments, or a candid conversation with a cross-team peer, only becomes useful once it's turned into a concrete plan with real milestones, not just a private intention to "do better." Structuring that plan around short checkpoints (for example, roughly 30, 60, and 90 days out), pairing each one with a way to actually show progress, and checking back with whoever raised the feedback rather than assuming the plan alone closes the loop is what separates a real development plan from a good intention that fades.

Structured elaboration

Clarify the specific behavior behind the label. A word like "ownership," "testing," "communication," or "business impact" can mean many different things in practice. Ask for a concrete example of what prompted the feedback, since the plan needs to target the actual behavior, not the label attached to it.

Build a milestone plan with visible checkpoints. An early checkpoint (roughly the first month) is about smaller, low-stakes practice: trying the specific behavior somewhere the cost of a misstep is low, and, where useful, pulling in a resource deliberately, whether that's a course, a mentor, or pairing with a colleague who's strong in that exact area, rather than just resolving to try harder. A middle checkpoint (roughly two months in) is about applying it in a real, higher-stakes setting and actively gathering a read on whether it's landing. A later checkpoint (roughly three months in) is about showing the behavior consistently across contexts, not just with one team or one person who already knows to expect it, and bringing concrete evidence back to whoever gave the original feedback.

Use resources deliberately rather than relying on willpower. A mentor, a targeted course, or pairing with someone strong in the gap area is usually far more effective than simply trying harder at the old approach; naming the specific resource used is part of what makes the plan concrete rather than aspirational.

Create your own way to see progress along the way. Feedback that matters doesn't only arrive at the next formal review; it can also show up informally, in a comment from a colleague or a passing remark. Building in a lighter self-check, or asking a trusted colleague to flag it if the old pattern resurfaces, keeps the plan honest between the big checkpoints.

Worked example

A manager's review notes that communication with other teams needs work, and the specific example given is that cross-team updates tend to arrive late and are too dense to act on quickly. In the first month, the update format changes to lead with the ask and the deadline, and early drafts get a quick review from a mentor before sending, as a low-stakes way to practice the new habit. In the second month, that habit gets applied in a real, higher-visibility setting: proactively posting a mid-sprint update to a cross-team channel before anyone has to ask for one, and paying attention to whether people are actually finding it clearer. By the third month, after several cycles of this, the pattern shows up in the threads themselves: cross-team updates that used to draw a "can you clarify" reply on roughly half of them are drawing one on maybe one in ten, and a direct check-in with a cross-team peer confirms updates now feel timelier and clearer. Both the count and the peer's read get brought back to the manager at the next check-in as evidence the specific behavior has changed, not just a claim that it has.

Trade-offs and pitfalls

Writing a plan and not revisiting it until the next annual review lets the good intention quietly lapse with nobody the wiser. Choosing milestones that describe activities (attended a course, read a book) rather than evidence that the underlying behavior actually changed makes the plan easy to complete without the feedback ever really landing. The other common failure is treating a specific example as an attack to be argued away instead of the concrete anchor it actually is; escalating defensively over one instance of feedback wastes the opportunity the specific example was giving you to target the plan precisely.

Direct answer

Agreeing with feedback in the moment produces no evidence of anything; I only trust that I have actually incorporated feedback when I can point to a specific behavior change that shows up again later, checked against a written record rather than my memory of having nodded along.

Structured elaboration

The core problem with relying on memory is that people, myself included, systematically overestimate how much they have changed based on a single instance of trying. A concrete system fixes that:

• Keep a running feedback log. Every time I get substantive feedback, I write it down close to when it happens: the date, who gave it, what was said, and the specific change I am committing to. This is the same kind of artifact some people call a growth plan or retrospective notes; the exact format matters less than that it exists and gets updated in the moment, not reconstructed from memory weeks later.
• Tie each entry to something observable, not a vague intention. "Write tests before merging" is checkable later; "be more careful" is not. If feedback arrives too vague to turn into a checkable behavior, I ask a clarifying question before logging it, rather than logging something I cannot later verify.
• Revisit the log on a fixed cadence, not only when reminded. I check it weekly while it is short, and specifically before one-on-ones (1:1s, regular individual meetings with a manager) and ahead of performance conversations, where I use the log as raw evidence rather than trying to reconstruct the last few months from memory.
• Treat recurrence as the sharpest signal. If the same feedback shows up a second time, that is stronger evidence that the change did not actually stick than any amount of me believing it did; a recurrence gets escalated into a more concrete, checkable commitment rather than a repeated promise to try harder.

Worked example

A manager once told me my pull request descriptions explained what changed but never why, which made review slower for everyone. I logged it that day with the specific commitment: every PR description states the reason for the change, not just its contents. Two weeks later, reviewing the log before a 1:1, I checked my last several PRs against that commitment and found the "why" was present in most, but had slipped on one that was written under time pressure. That single recurrence told me the habit had not fully stuck yet, so instead of just recommitting verbally, I added a "why" field to the team's PR template, which turned the commitment into something the process enforced rather than something I had to remember unaided. I brought that log entry, including the slip and the fix, into my next 1:1 and later cited it in a self-review as concrete evidence of acting on feedback rather than just agreeing with it.

Trade-offs and pitfalls

It is possible to over-engineer the tracking itself into busywork, logging feedback in exhaustive detail without ever actually reviewing the log, which defeats the point. Conflating "I remember agreeing with it" with "I changed" is the exact failure mode this whole system exists to catch, so skipping the periodic review and trusting memory instead quietly reintroduces the problem. Tracking only critical feedback and never noting what is already working can also mislead, since it produces a lopsided, overly self-critical picture rather than an accurate one. Finally, a log that only gets opened right before a performance review, instead of on a regular cadence, provides much weaker evidence, since by then it is too late to correct course on anything that slipped months earlier.

Direct answer

Feedback that challenges a core assumption stings more than a detail-level correction because it threatens the whole plan you've invested in, not one line of it. The discipline is separating "how much work I've put in" from "whether the assumption is actually still true," and evaluating the challenge on evidence rather than on how costly it would be to admit you're wrong.

Structured elaboration

1. Reacting personally in the moment. Name it, at least to yourself, that a core-assumption challenge feels bigger than a detail challenge because more is genuinely at stake: sunk time, a plan already communicated to others. That recognition helps you avoid conflating "this is uncomfortable" with "this is wrong."
2. Evaluating whether it's right. Go back to why you made the original assumption, what evidence or context it was based on, and ask whether the challenger has new information or is reading the same information differently. This is different from a detail-level fix, since you may need to re-derive from the assumption forward rather than patch one component.
3. What changes. Ranges from a full pivot, if the assumption really doesn't hold, to a scoped adjustment, if part of it holds and part doesn't, to a respectful, evidence-based defense of the original assumption, if it genuinely still holds. The size of the challenge doesn't automatically determine the size of the correct response.

Worked example

I proposed a caching layer built on the assumption that read traffic was overwhelmingly for recent data, that most requests hit the last 24 hours. A colleague challenged that core assumption directly, arguing a meaningful chunk of traffic was from a batch reporting job pulling much older records, which would make my cache design ineffective for a large share of real traffic. My first internal reaction was defensive, since the whole design rested on that assumption. I went back to the actual traffic logs rather than my memory of them, and the challenge held: a substantial share of read volume was from that older-data batch job, which I'd missed because I'd looked at request count by hour and hadn't separated it by data age. That changed the design meaningfully, not just a tuning parameter: I split the cache into a hot-recent tier and a separate warm tier sized for the batch job's access pattern, instead of one undifferentiated cache.

Trade-offs and pitfalls

Treating a core-assumption challenge as automatically requiring a full scrap-and-restart is as much a mistake as reflexively defending the original assumption; sometimes checking the evidence confirms the assumption was right and the challenge was based on a misunderstanding, and defending it calmly with the evidence is the correct, non-defensive response. The amount of prior investment in the original plan is not evidence about whether the assumption is true, and letting sunk cost drive the evaluation is the single most common failure mode here. Re-deriving from the challenged assumption forward, rather than only patching downstream symptoms, is what separates a genuine reassessment from a surface fix that leaves the same flawed foundation underneath.

Direct answer

A missing "business ask" almost always means the deck led with the how before the why. The fix isn't extra technical detail, it's resequencing: open with the decision you want leadership to make, the cost or risk of not deciding, and what you need from them, then let the technical material back that up rather than precede it.

Structured elaboration

Before rewriting anything, confirm what the peer actually meant (a clarifying question, not a defensive one): was the ask missing entirely, buried on slide 12, or present but not quantified? Then rebuild the opening around three questions leadership needs answered in the first minute: what decision are you asking them to make, what happens if they don't make it, and what do you need from them (budget, headcount, a go or no-go). Everything technical moves later or into an appendix, reordered to support that ask rather than lead it.

Worked example

As a Solutions Architect who'd presented a cloud migration recommendation, a peer told me the deck opened with an architecture diagram and only mentioned cost on the last slide, so leadership left unsure what they were being asked to approve. I rebuilt the opening into three slides. Slide 1: the ask, stated as a single sentence, approve a phased migration starting next quarter, with the decision needed by a specific date. Slide 2: why now, framed as the cost of the status quo (rising licensing spend, an aging platform nearing end of vendor support) against the expected payoff of migrating, kept qualitative rather than over-precise since some of those figures were still estimates. Slide 3: what we need from leadership, namely budget approval and one sponsor to unblock a cross-team dependency, plus a single line naming the main trade-off (a short migration freeze window). The architecture diagram moved to an appendix slide referenced only if someone asked.

Trade-offs and pitfalls

The risk in "make it more business-focused" feedback is over-correcting into a deck with no technical grounding, which invites a different complaint from a technical reviewer in the room. Keep enough technical framing that the ask is credible, just after the ask, not before it. It's also worth checking the rewritten opening with the peer before the real meeting; a clearer ask is subjective, and a quick gut-check catches a miss before it costs you the room.