Coachability, Feedback, and Humility Questions

Direct answer

Executive presence feedback is frustratingly vague on its own, so the first move is unpacking it into things you can actually practice: how you're perceived as credible and composed under pressure, whether you can tell a coherent story instead of listing facts, and how you deliver technical material to an audience that doesn't share your context, then build a 3-month plan around those pieces rather than one generic goal to be more confident.

Structured elaboration

A concrete plan usually has:

• Credibility: coming into briefings with a clear point of view and a recommendation, not just a status report, since credibility with senior leaders often comes from demonstrating judgment, not just knowledge.
• Storytelling: structuring updates around a narrative arc (what happened, why it matters, what's next), instead of a chronological list of technical events.
• Delivery of technical topics: translating system-level detail into business-relevant terms without dumbing it down, practiced deliberately rather than improvised live in front of leadership.
• Executive presence itself: composure under pointed questioning, which is mostly a rehearsed skill, anticipating the hard questions in advance and practicing calm, direct answers rather than getting flustered.

Worked example

As a Site Reliability Engineer, I got direct feedback after a reliability briefing that I'd read too much like a status report and hadn't projected confidence when a VP pushed back on a timeline. My 3-month plan: month one, I sat in on two briefings led by a senior engineer known for handling this well and noted specifically how they opened with a recommendation before the details, and I recorded myself giving a mock briefing to review my own pacing and filler words. Month two, I restructured how I prepared for briefings, always leading with a one-line recommendation and the "why now," and rehearsed the two or three toughest questions a leader might ask before each real briefing rather than improvising responses live for the first time. Month three, I asked a manager to sit in on two real briefings and give me direct feedback afterward on composure and clarity specifically, and by the second one, the manager noted I held my answer steady instead of over-explaining when pushed on a timeline, the same pattern that had triggered the original feedback.

Trade-offs and pitfalls

The pitfall is treating this as purely a performance skill, posture, tone, confidence, and skipping the substance side, since executive audiences generally sense a lack of a real point of view underneath polished delivery. The other is over-rehearsing to the point of sounding scripted, which can read as less credible than a slightly rougher but clearly genuine answer.

Direct answer

When feedback lands that seems based on a misunderstanding, I resist the urge to immediately correct the other person and instead ask clarifying questions to find out exactly what they think happened. That usually surfaces the misunderstanding faster, and with less friction, than defending myself outright.

Structured elaboration

In the moment. I listen fully before responding, resist forming a rebuttal while the other person is still talking, and treat the feedback as their honest read of what they observed, even if I suspect it is based on incomplete information.

Clarifying questions. I ask specific, non-defensive questions aimed at understanding their view of the situation, not at proving them wrong, such as "can you walk me through what you saw that led you to that?" or "what would the right version have looked like to you?" These usually reveal exactly where the disconnect is without me having to assert anything yet.

Confirm before correcting. Once I think I see the misunderstanding, I check it gently rather than declaring it, since it is possible I am the one missing something, not them.

Afterward. I identify what made the misunderstanding possible in the first place, was the work not visible enough, was a decision undocumented, was there a communication gap, and fix that root cause, not just this one instance.

Worked example

Situation: a reviewer said my API design was inconsistent with the rest of the service and pushed back on it as sloppy.

Task: check whether their read was accurate before disagreeing further.

Action: instead of immediately explaining my reasoning, I asked what specifically looked inconsistent. They pointed to two endpoints using different pagination styles. I realized they were comparing my new endpoint to an older, deprecated pattern that had actually already been flagged for replacement, information they did not have. I confirmed it gently: "it sounds like you're comparing this to the older pagination style, that one's actually being phased out, my endpoint follows the new standard we agreed on last quarter, do you have the design doc from that?"

Result: once they saw the doc, they agreed the new endpoint was the consistent one; the actual inconsistency was in the old code, not mine. Afterward, I realized the new standard was not linked from the code or the pull request description, so a reviewer without recent context had no way to know. I added a link to the standard in the pull request template so future reviewers would not hit the same gap.

Trade-offs and pitfalls

Correcting the person immediately and confidently can come across as dismissive even when you turn out to be right, and can make them defensive in return. Capitulating to feedback that felt wrong just to avoid conflict, without ever finding out it was based on a misunderstanding, means a real fix, like linking the standard, never happens. Asking clarifying questions takes longer in the moment than just asserting the correct answer, but it is what actually surfaces whether you, not just them, are the one missing something.

Direct answer

Feedback like this has to be accepted without minimizing it first: "the way I pushed for technical decisions made people afraid to disagree with me" is a statement about impact, not intent, and arguing intent is the fastest way to make it worse. From there the work is concrete behavior change, a way to check it's actually landing, and rebuilding trust deliberately over time rather than assuming an apology fixes it.

Structured elaboration

Accepting the feedback
I resisted the urge to explain my reasoning first and instead asked for specific instances: which meeting, whose idea got steamrolled, what did I actually say or do. A label like "reduced psychological safety" (the sense that people can speak up, disagree, or admit a mistake without fear of being punished or embarrassed for it) is only actionable once it's tied to real moments.

Changing behavior
The concrete changes were specific and observable, not a vague "I'll listen more": asking for others' positions before stating my own in design discussions, explicitly inviting the counter-argument, "what's the strongest case against this," instead of just tolerating it if it came up, and not interrupting when someone was still working through an idea out loud.

Measuring improvement
I looked for behavioral evidence rather than self-assessment: were junior engineers proposing alternatives in design review without being prompted, did dissent start showing up in written docs and not just hallway conversations, did the person who raised the original concern start speaking up again on unrelated topics.

Rebuilding trust
This took consistency over weeks, not a single gesture. I checked in individually with the people most affected rather than only addressing the team broadly, and I made a point of being visibly wrong in front of the team at least once and taking the correction well, since modeling that mattered more than promising it would happen.

Worked example

In the design review where this surfaced, I'd been cutting off a proposal I disagreed with before the presenter finished. The changed version of that same kind of meeting looked like: let the proposal finish uninterrupted, ask "what am I missing" before stating a counter-position, and if I still disagreed, say so as one input into a decision rather than as a verdict. Over the following review cycles, the same presenter started bringing harder, more contrarian proposals to the table, which was the clearest sign the safety had come back.

Trade-offs and pitfalls

The overcorrection is real: swinging from "pushes too hard" to "never advocates for a technical position" just replaces one problem with a different one, indecisive leadership. The goal isn't to stop pushing for good decisions, it's to separate advocating strongly for an idea from punishing people for disagreeing with it. It's also a mistake to treat one round of behavior change as done. This kind of feedback tends to recur if the underlying habit isn't actually broken, so the check-in has to continue past the point it feels resolved.

Direct answer

In the moment, say plainly that you don't yet know, without guessing out loud to fill the silence, immediately pair that admission with a concrete next step so it doesn't sound like a dead end, and afterward protect trust by actually following through on that plan and closing the loop even if the answer takes longer than hoped.

Structured elaboration

• Handling the moment. Resist the pressure to speculate confidently just to have something to say; a wrong guess stated as fact is worse than an honest "I don't know yet," because it can send the stakeholder's own decisions in the wrong direction. Say it plainly: "I don't have a confident answer for why that happened yet."
• Proposing an investigation plan on the spot. Immediately follow the admission with a specific next step and, if possible, a rough timeframe: "I'm going to check X and Y first, and I'll have an update by [a specific time]," rather than an open-ended "I'll look into it." This converts "I don't know" from a dead end into a plan the stakeholder can trust is moving.
• Maintaining trust during follow-up. Actually deliver on the timeframe given, even if the update is "still investigating, here's what I've ruled out so far," rather than the final answer. A stakeholder tolerates not having the answer yet far better than they tolerate silence after being promised an update. If the investigation takes longer, or turns up something uncomfortable, including a mistake, say that plainly too rather than softening it.

Worked example

A stakeholder asks why a report's numbers jumped overnight, and there's no confirmed reason yet. Instead of guessing, "probably a data refresh issue," the response is: "I don't have a confirmed reason yet, I don't want to guess and send you down the wrong path. I'm going to check the two most likely sources, the upstream data feed and a recent code change, and I'll update you by end of day either way." The follow-up happens by end of day as promised, even though the investigation isn't finished: "I've ruled out the code change, still checking the data feed, will have a final answer by tomorrow morning." The next day brings confirmation that it was an upstream data quality issue, along with what's being done about it. Trust holds because every promise about timing was kept, including the intermediate ones.

Trade-offs and pitfalls

Guessing confidently to avoid looking uninformed risks being wrong, which costs more trust than the original "I don't know" would have. Saying "I don't know" with no plan attached reads as unhelpful rather than honest. Promising a timeframe and then going silent when it's not met damages trust more than the original uncertainty did. And over-apologizing or being defensive in the moment can make the stakeholder more anxious rather than reassured that it's being handled.

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.