Scenarios: credit, feedback, and visibility

Credit and feedback are where the quiet, high-stakes conversations happen, and most of us fumble them because we react instead of reply. This is a dense bank of real exchanges shown from both chairs: sometimes you are the one whose work got claimed or whose feedback landed wrong, and sometimes you are the reviewer, the manager, or the person who forgot to say your name. Every one softens the person and sharpens the substance. Skim for the situation that matches yours and steal the reply.

Someone takes credit for your work

  • A peer presents your migration as theirs. Q: "So I moved us off the old queue and cut p99 by 40%." A: "Glad that number landed well. For the record, that was the plan Dana and I paired on for two weeks; happy to walk anyone through the internals."
  • Standup, they narrate your fix. Q: "I patched the auth timeout this morning." A: "Quick note, I shipped that patch last night in PR 812. Happy to hand off the follow-up cleanup if you want it."
  • Your manager thanks the wrong person. Q: "Big thanks to Ravi for the dashboard rewrite." A: "Ravi reviewed it, which helped a lot. I wrote it, so send the questions my way and I will keep it moving."
  • Slack, a lead posts your diagram as theirs. Q: "Made this architecture diagram for the review." A: "That is the one from my design doc last week, link here. Fine to reuse, just tag the source so people find the full context."
  • In a demo, they say "we" but mean you. Q: "We got the caching layer working." A: "To be concrete about ownership: I built the caching layer, Sam load-tested it. Ask either of us."
  • You both built it, so tread carefully. Q: "I designed the retry logic." A: "We designed it together on Tuesday, and I want the reviewers to know that so questions route to both of us, not just one."
  • Retro, someone claims your idea's outcome. Q: "My idea to batch the writes saved us the incident." A: "That batching came out of the thread I opened in eng-infra on the 3rd. Good that it paid off; I can share the reasoning for next time."
  • Written status report drops your name. Q: (report reads) "Platform team delivered SSO." A: "Could we credit contributors by name in the report? I owned the SSO integration and want it discoverable when someone hits a bug."
  • A senior repeats your point as their insight. Q: "What we really need is idempotency keys on that endpoint." A: "Right, that is exactly what I flagged in the review comment, so we are aligned. I can draft the keying scheme today."
  • You are the manager crediting a report. Q: (writing shout-out) "Team shipped the export feature." A: "Naming names: Noor built the export pipeline end to end and Tomas reviewed. Credit where it is due."
  • You are the reviewer who almost claimed a fix. Q: "I'll say I found the null-deref in the demo." A: "Actually Marta found it in her review, I just merged. Let me credit her so the pattern gets attributed right."
  • Vendor call, a colleague speaks over your work. Q: "I handled the whole integration on our side." A: "To be precise for the vendor: I owned the API integration, Alex owned the auth handshake. Loop us both on issues."
  • Someone forwards your doc without attribution. Q: "Sharing this runbook I put together." A: "That is the runbook from my on-call notes, glad it is useful. Mind adding the original link so edits sync back?"

Your idea is presented without you

  • Your Slack idea resurfaces in a meeting. Q: "I think we should shard by tenant, not by region." A: "That is the approach I sketched in the thread Monday, so strong agree. I can turn it into a design doc this week."
  • A manager pitches your proposal upward. Q: "I'm proposing we move to feature flags for the rollout." A: "Happy that is getting traction. I wrote the flag proposal in the wiki, link here, so the details are already there when leadership asks."
  • Someone builds a deck on your notes. Q: "I pulled together this plan for Q3." A: "A lot of this is from my planning doc, which is great. Can we add me as a contributor so I can field the technical questions?"
  • You spot your framing used as theirs. Q: "The real problem is coupling, not scale." A: "That is the framing from my write-up, and I stand by it. I have the data behind it if we want to make the case airtight."
  • Casual DM before you go correct it. Q: (peer) "Did you see they used your load-test idea and never said your name?" A: "I did. I will drop a friendly note with the original link rather than call it out live."
  • You are the one who forgot to attribute. Q: "Wait, whose idea was the read-replica split?" A: "That was Priya's, from her comment on PR 640. I should have said so up front; correcting now."
  • Threaded reply reclaiming quietly. Q: (thread) "Great suggestion to cache the tokens." A: "Thanks, that built directly on the caching idea I raised in the design review; nice to see it land."
  • Leadership asks who owns the idea. Q: "Who came up with the event-sourcing approach?" A: "Ines proposed it in the architecture channel three weeks ago. She should walk you through the trade-offs."
  • Your prototype shown as a finished pitch. Q: "Here's the new onboarding flow." A: "That is my prototype from the hack day, and I would love to finish it. Can we scope it in properly with me on it?"
  • You want credit without a scene. Q: (the reactive DM you almost send) "Hey, that was my idea, why not mention me?" A: (the version you send instead) "Hey, glad the tenant-sharding idea landed. Could you add my name when it comes up? Happy to own the doc."

Don't be confused: claiming credit and building on an idea are not the same thing. When someone extends your idea and says so, that is collaboration, so thank them. Only reach for a correction when your name is being erased, and reach for the version that adds a link, not the version that adds heat. See Chapter 26 for the difference between winning a point and fixing the record.

Giving negative feedback to a teammate

  • Their PR has no tests. Q: (you open the review) "Can I add a couple of tests?" A: "This logic is tricky enough that I would not merge it untested. Can you add cases for the empty-input and timeout paths before we ship?"
  • A junior keeps force-pushing over review. Q: "I updated the branch." A: "Heads up, force-pushing after I start reviewing loses my in-progress comments. Could you push new commits instead until we approve?"
  • Someone's design doc is vague. Q: "Does the design look good?" A: "The shape is right. It is too abstract for me to sign off yet: what is the failure mode when the vault service is down, and what is the rollback?"
  • Repeated missed standups. Q: (1:1) "Anything to raise?" A: "One thing: you have missed standup three days running. If the time does not work, let us move it. If something is up, I would rather know."
  • A peer's commits break the build weekly. Q: "CI is red again, weird." A: "It has been red on your merges four times this month. Can we agree to run the suite locally before merge? Happy to pair on making that fast."
  • Their Slack tone reads sharp to others. Q: (DM) "Got a sec?" A: "Small thing, said kindly: a few people read your 'this is obviously wrong' replies as harsh. The point is fine, the wrapper stings. Worth softening."
  • You are the manager, performance is slipping. Q: (1:1 open) "How are things?" A: "I want to be direct because I respect you: your last two projects landed late without a heads-up. Let us figure out what is getting in the way."
  • Code is clever but unreadable. Q: "Pretty elegant, right?" A: "It is clever, and that is the problem. The next on-call person will not follow it at 3am. Can we trade three lines of cleverness for ten of plain?"
  • A teammate over-promises in planning. Q: "I can get all five done this sprint." A: "I would rather you commit to three and deliver than promise five and slip. What are the two you would cut if the week goes sideways?"
  • Peer keeps reviewing at the surface. Q: "LGTM, nice work." A: "Can I ask for a deeper pass? A rubber-stamp does not help me catch the concurrency bug. Poke at the locking in particular."
  • You are the reviewer, softening a hard no. Q: (author) "Can we merge and fix forward?" A: "Not this one; it touches billing and the edge case double-charges. I will pair with you now to fix it properly, should be quick."
  • Their estimate ignored the migration. Q: "Two days, easy." A: "Two days for the feature, sure. It also needs a data migration for eight million rows, which is not two days. Let us re-estimate with that in."
  • Feedback on a teammate's writing. Q: "Is the RFC clear?" A: "The argument is strong. It buries the decision on page four; move the recommendation to the top so busy readers get it in ten seconds."
  • You are the manager naming a pattern, not a day. Q: (1:1) "Was yesterday okay?" A: "Yesterday was fine. The pattern I want to name is interrupting in reviews: it costs you goodwill you have earned. Small fix, big return."

Don't be confused: feedback is not the same as venting. Venting makes you feel better; feedback is aimed at a change the other person can actually make. If you cannot name the specific next action ("add the timeout test", "push commits instead of force-pushing"), you are not ready to give it yet. More on structuring the hard version in Chapter 11.

Feedback that feels unfair

  • You are told you missed a deadline you never got. Q: "You were late on the report." A: "I want to fix this, so let me check my understanding: I had it down for Friday and delivered Thursday. Was there an earlier date I missed?"
  • A review calls your code sloppy. Q: "This is sloppy." A: "Help me act on that: which parts? If it is naming, I will rename. If it is the structure, I would push back, so let us look at a specific line."
  • Manager says you dropped the ball on comms. Q: "You should have told me." A: "Fair to want earlier notice. I did post it in the channel on the 3rd; maybe that is the wrong place to reach you. What channel do you actually read?"
  • Blamed for another team's outage. Q: "Your service caused the eu-west outage." A: "Let us look at the timeline together. My service returned 200s the whole window; the timeouts started upstream at the gateway. Here is the trace."
  • Harsh feedback delivered in public. Q: (in the meeting) "This design is a mess." A: "I hear the concern. Can we take the specifics offline right after? I want to get to what is actually broken, not just that it feels off."
  • You did cause it, and the feedback is fair. Q: "You shipped without a rollback plan." A: "You are right, I did, and that was a real miss. Rollback is written now and I am adding it to my pre-ship checklist so it does not repeat."
  • Feedback based on a rumor. Q: "I heard you are hard to work with." A: "That is worth taking seriously, so I want the specifics. Who, and on what project? Secondhand I cannot fix; a concrete example I can."
  • Rated low on impact despite shipping. Q: "Your impact was limited this half." A: "I would like to reconcile that. I shipped SSO and cut on-call pages by half. Can we walk through what impact means so I aim right next time?"
  • You are the manager getting pushback on your feedback. Q: (report) "That feels unfair, I hit my dates." A: "Then I may have it wrong; show me. If the dates check out, I will correct the note and we move on."
  • Feedback is real but the tone was rough. Q: "You never document anything." A: "The docs gap is real and I will close it. I would ask for 'rarely' over 'never', because the on-call runbook was mine, and I want us working from the same facts."

Manager says your communication needs work

  • Vague feedback in a review. Q: "Your communication needs work." A: "I want to improve, so I need a handle on it. Is it written updates, speaking in meetings, or how I raise blockers? Give me one recent example to anchor on."
  • You over-explain in updates. Q: "Your status updates are too long." A: "Got it. I will switch to three lines: what shipped, what is blocked, what is next. Flag me if I still bury the point."
  • You go silent when blocked. Q: "I never know when you're stuck." A: "That is on me. New rule for myself: if I am blocked more than two hours, I post it. You will see more of me, not less."
  • Meetings, you stay quiet. Q: "You should speak up more in reviews." A: "Fair. I tend to process before I talk. I will come with one written point per review and say it early so I do not lose the window."
  • Your writing assumes too much context. Q: "People can't follow your docs." A: "Useful, thank you. I will add a one-paragraph 'what and why' at the top of each doc. Point me at the worst offender and I will fix it first."
  • You bury bad news. Q: "You told me about the slip too late." A: "You are right. From now I will raise a risk when it is 'might slip', not 'has slipped'. Earlier and rougher beats late and polished."
  • Told you sound defensive in reviews. Q: "You get defensive on feedback." A: "I would rather not, so I am glad you said it. I will start replies with the part I agree with before I push back. Call it out if I slip."
  • You are the manager giving this feedback. Q: (1:1) "One growth area?" A: "Your comms. Concretely: your PRs land with no description, so reviewers reverse-engineer intent. One sentence of 'why' per PR would change how fast you get approved."
  • Asked to tailor to the audience. Q: "You talk to execs like engineers." A: "Right, I lead with the mechanism when they want the outcome. I will open with the impact and the ask, then keep the internals for the appendix."
  • You want a way to measure progress. Q: "Just improve your communication." A: "I will, and I want a checkpoint. Can we look at three of my updates in a month and you tell me if they are landing? Otherwise I am guessing."

Manager says you are not visible enough

  • Told your work is invisible. Q: "Leadership doesn't know what you do." A: "Then let us fix the signal, not the work. I will post a short weekly win in the team channel and demo one thing a month. Point me at the room that matters."
  • You do the glue work no one sees. Q: "Your impact isn't legible to skip-level." A: "A lot of it is unblocking others, which is quiet by nature. I will start logging who I unblocked and how, so it shows up in writing, not just in vibes."
  • Encouraged to demo more. Q: "You should present at the eng review." A: "Happy to. I will take the caching project to Thursday's review, ten minutes, results-first. Anything specific leadership wants to hear?"
  • Manager wants you known cross-team. Q: "Other teams don't know your name." A: "I will write up the rate-limiter as an internal post and offer to consult when teams hit the same wall. That puts my name on the solution, not just the code."
  • You dislike self-promotion. Q: "You need to advocate for yourself." A: "I would rather let the work speak, but I hear that it needs a voice. I will report outcomes plainly, not sell. Facts and numbers, not adjectives."
  • You are the manager coaching visibility. Q: (1:1) "How do I get promoted?" A: "Your work is strong and quiet. Pick one project a quarter and make it visible: a demo, a doc, a talk. I will sponsor you into the rooms."
  • Told to claim your wins in the review doc. Q: "Your self-review undersells you." A: "I will rewrite it with specifics: shipped X, cut Y by 30%, mentored Z. Less 'helped with', more 'owned and delivered'."
  • Visibility versus grandstanding. Q: "Just be louder in meetings." A: "I will be more present, though I would rather be useful than loud. I will bring one sharp point per meeting instead of filling air."
  • Manager offers you a stage. Q: "Want to run the postmortem readout?" A: "Yes. I owned the fix, so I should tell the story. I will keep it blameless and lead with what we changed."
  • You want visibility to reflect the team. Q: "Take credit for the launch in the all-hands." A: "I will represent it, and I want to name the three people who did the heavy lifting. Visible and fair are not in tension here."

Asking why a decision was made without sounding confrontational

  • A design choice surprises you. Q: (the sharp version) "Why did we pick DynamoDB over Postgres?" A: (the version that lands) "I want to understand the DynamoDB call so I stop second-guessing it: what pushed us off Postgres, the write volume or the ops load?"
  • A decision was made without you in the room. Q: "We're going with the vendor API." A: "Makes sense there was a reason, I just missed the discussion. What ruled out building it in-house? I want the context before I build against it."
  • Curiosity, not challenge. Q: "We set the timeout to 30s." A: "Genuinely curious about the 30s: was that measured off p99, or a round number we can revisit? Either is fine, I just want to know which."
  • You think the decision is wrong but ask first. Q: "We're dropping the retry logic." A: "Before I react, help me see it: what made retries not worth it here? If it is the duplicate-write risk, I might have a way to keep both."
  • A priority got reshuffled. Q: "We're pausing the migration." A: "No pushback, I just want to plan around it: what moved ahead of it, and is the pause a week or a quarter?"
  • You are the manager who made the call. Q: (report) "Why did we cut the feature?" A: "Good to ask. The vendor deadline forced a trade and this was the least load-bearing piece. If that reasoning has a hole, tell me."
  • Asking upward without stepping on toes. Q: "Leadership picked the reorg structure." A: "I trust there was thinking behind it. Could someone share the goal it is optimizing for? I will get behind it faster if I know the target."
  • A code standard you would not have chosen. Q: "We're standardizing on tabs." A: "Fine either way, honestly. I am just curious what settled it, so I do not reopen a closed debate later."
  • You want the reasoning documented. Q: "We chose gRPC for the internal calls." A: "Solid. Could we drop the why in an ADR? Not to relitigate, just so the next person does not ask me the same question in six months."
  • A rollback of your own approach. Q: "We reverted your caching change." A: "Understood, and I want to learn from it rather than defend it: what did it break, and would a narrower version have been okay?"
  • Decision feels rushed but you stay open. Q: "We're shipping Friday, decided this morning." A: "That is quick, so I want to make sure I am not missing a driver: is there a date we are hitting, or room to sanity-check over the weekend?"

👉 Knowing what to say is half of it; the other half is tone, timing, and how you follow up when the first message lands wrong. On to Chapter 55.