CareerClimbCareerClimb
Office Politics
Visibility
Promotion
Career Skills
March 6, 20266 min read

What to Do When Someone Takes Credit for Your Work

What to Do When Someone Takes Credit for Your Work

You're in a meeting. Your manager is nodding, impressed. The feature you spent three weeks designing and building, the one that just got praised, is being described by someone else as their approach.

You sit there watching it happen, not sure whether to interrupt or let it go.

That moment of paralysis is what this article is about. Credit theft in tech is common, and the instinct is usually wrong in both directions: staying silent lets the record stand, but speaking up badly makes you look petty. There's a better path, and it starts before you even get into that meeting.

Why credit theft costs more than the moment

Your promotion case is built on evidence of your impact. Not team impact. Not project impact. Yours, specifically.

When a colleague presents your work as theirs, what gets written into your manager's memory (and eventually into your promotion writeup) is their name, not yours. Managers don't audit every decision and commit to reconstruct who did what. They remember who they heard talk about the work.

On Team Blind, where engineers post with verified company email badges, this pattern comes up repeatedly. One engineer described it directly: when a peer takes credit for a high-visibility project, "you miss the cycle because your manager can't point to anything concrete, even though you built the thing." In systems where promotion evidence needs to be specific and documented, invisible contributions don't count.

Two situations, different responses

Not all credit situations call for the same approach. How you respond depends on who did it.

When a peer takes credit

This is the more common case. A colleague presents your work in a meeting, writes it up in a report, or mentions it in their self-review without attributing you. Sometimes it's deliberate. Sometimes they genuinely didn't think to credit you. You often can't tell which, so your response should leave room for both.

When your manager takes credit

This is harder to navigate. A manager presents team output to their skip-level and says "I built a system that..." without crediting the engineers who actually wrote it. Sometimes this is how managers see their role: they "built" it by leading the team. Sometimes it's more self-serving. Either way, the conversation is different, and the risk of handling it poorly is higher.

What to do in the room, right then

If you catch it happening in a meeting, the move is calm, specific redirection that doesn't put anyone on the defensive.

Something like: "Thanks for bringing that up. I'll add some context: I led the design and implementation of the caching layer, which is what drove the 40% latency drop. Happy to walk through the technical details if it's useful."

Notice what this does: it attributes the work to you without accusing anyone. It's specific. And it offers something to the room (a walkthrough), so it doesn't read as point-scoring.

If you didn't catch it in the moment and only realized afterward, don't try to relitigate it in Slack or email. That's where it starts to look bad. Take it to your manager instead.

Having the conversation with your manager

If a peer took credit in a meeting your manager attended, address it in your next 1:1. Frame it as a factual clarification about your contributions, not a complaint.

A script that tends to work:

"I wanted to flag something about last week's project review. [Colleague] walked through [feature] as their work, and I want to make sure you have the full picture. I authored the design doc and led the implementation; here's the PR history and the doc I wrote on [date]. I'm not trying to create a problem, but I want my work to be visible for my case this cycle. How would you suggest we handle something like this going forward?"

A few things this gets right:

  • Evidence first: your PR history, the design doc, the date you authored it. No evidence means your manager can't act on it.
  • Name the specific incident, not a general pattern. "They presented [feature] without my name" is a concrete claim. "They always steal credit" invites debate.
  • Frame it around your promotion case, not grievance. Your manager moves faster on "I want my work visible for my review" than on "I feel disrespected."
  • End with a question. That turns it from a complaint into a shared problem to solve.

Going to your manager without documentation is the version that backfires. Saying "they took credit for my work" with nothing to point to leaves your manager in an uncomfortable spot: they either take your word for it, or they investigate, or they file it as "interpersonal tension" and move on. Most choose the third option.

Does confronting the person directly help?

Sometimes. Rarely in cases of deliberate theft, more often in cases of genuine obliviousness.

If you have a reasonable relationship with the person and think they might not have realized what they did, a private, low-key conversation can clear it up:

"Hey, I noticed the latency project got brought up in the review. I kicked off the initial design on that. If it comes up again, maybe we can co-present or you can give a quick shoutout to the team? No pressure either way."

This leaves them room to have been careless rather than malicious. Most people, approached this way, will say "of course, sorry about that" and be more careful.

If this is a pattern, or if you're dealing with someone who does this deliberately, skip the direct conversation and go straight to your manager with documentation. Engineers on Team Blind and r/cscareerquestions who've tried confronting serial credit thieves consistently report the same outcome: the thief denies it or turns the conversation around, and you end up looking like the problem. When credit theft is part of a broader pattern of undermining, blame-shifting, or manipulation, the calculus changes. Working alongside a toxic coworker requires a different overall approach than managing a one-off incident.

How to make your ownership impossible to steal

The most durable protection against credit theft isn't knowing how to recover. It's making your contributions visible and traceable before anyone can claim them.

Write up your proposals. When you're proposing an approach, post it somewhere that timestamps your thinking. A Slack message saying "Proposing [feature] to solve [problem]. Here's the design I put together: [link]. Feedback welcome" establishes your ownership publicly, without any confrontation required.

Commit messages are also working for you. Not fix bug but something like reduce latency in auth service by replacing N+1 queries with batch fetch (closes #1234). Commit history is auditable, searchable, and your name is on every line.

Weekly updates to your manager give them something specific to remember. Not a laundry list, but something concrete: "This week: shipped the auth refactor (PR #123), which cut error rates by 30% for users on mobile." Your manager files this away and reaches for it when writing your review.

The same logic applies at standups. Not bragging, just precision. "I merged the PR for the notification system refactor yesterday, which unblocks the frontend team" is a sentence that puts your name on a fact. Vague contribution ("worked on the notification system") is easier to claim.

Engineers who consistently avoid credit theft problems aren't luckier. They've built habits that make their ownership obvious. Their fingerprints are on their work in ways that leave little room for misattribution. That consistent documentation is also the foundation of effective self-promotion: not bragging, but building a traceable record of what you actually did.

When your manager is the one doing it

If your manager presents the team's output without crediting individual contributors, the direct conversation is usually not the right move. Most of the time, this is just how managers talk about their team's work to leadership, and pushing back risks a relationship you need.

The more practical approach: make your work visible beyond your immediate manager. Present in broader team meetings when the opportunity arises. Build relationships with your skip-level. Write things up where they're searchable. If your contributions are documented and visible in ways that others can see, your manager narrating the team's results doesn't erase your individual record.

If it's more severe, specifically when your manager is actively misrepresenting who did what in ways that affect your review, that's a harder situation. When your manager takes credit for your work covers that specific dynamic and what to do about it.

Start documenting before it happens again

The engineers who get credit consistently aren't working harder than the ones who don't. They're working visibly. They log the decision they made in a doc. They send the update. They say the thing in the meeting.

Frequently Asked Questions

Related Articles