Make your contribution visible by naming the team result and then describing your specific responsibility, decision, and evidence. You can share credit and still use “I” accurately. Avoid both extremes: taking ownership of a collective outcome and describing your own work so vaguely that no one can evaluate it.
“We shipped the migration” may be true. It does not tell the listener whether you designed the approach, implemented one component, coordinated the rollout, or reviewed the risk. Those contributions can all matter, but they demonstrate different things.
Aida’s reflection on downplaying individual contributions describes the cost of letting team language obscure a personal role. The answer is more precise attribution, not louder self-promotion.
Use two sentences instead of choosing between “I” and “we”
Begin with the shared result. Then name your part. For example: “Our team completed the service migration. I owned the compatibility review and rollout checks; Elena led the data migration, and Jamal implemented the client changes.”
That description gives collaborators credit and makes your work assessable. Add the result of your contribution where it is known: the review identified an unsupported client version, the checks caught a staging failure, or the rollout procedure was adopted. Do not claim the whole project’s benefit as exclusively yours.
Choose verbs that describe what happened
Scroll sideways to see all columns.
| Vague phrase | More precise alternative | Evidence to attach |
|---|---|---|
| Helped with the design | Identified the compatibility constraint and proposed the fallback | Design comments and decision record |
| Led the project | Owned the rollout plan and coordinated release decisions | Plan, responsibilities, and decision notes |
| Mentored the team | Reviewed two designs and taught the debugging method used in the fix | Review artifacts and specific feedback |
| Improved reliability | Implemented the check for the reproduced retry failure | Change, test, release, and any measured outcome |
Use “led” when you can explain what you led. A title alone is not evidence, and doing most of the implementation is not automatically the same as leading the project. Choose the description that a collaborator would recognize.
A fictional shared project, written three ways
Too small: “The team did a great job. I just helped with a few reviews.” This hides the possibility that those reviews changed an important decision.
Too large: “I delivered the migration and eliminated deployment risk.” This assigns the collective result to one person and makes an absolute claim about risk.
Specific: “The team delivered the migration. I identified an old-client compatibility gap during review, proposed a staged rollout, and worked with the client lead to add a release gate. The gate caught one incompatible path in staging. The implementation and data migration were owned by other engineers.”
The third version is neither modest nor boastful. It is inspectable. A reviewer can understand the contribution and ask about its scope without guessing what “helped” means.
Put the information where a decision needs it
Visibility does not require posting every accomplishment to the largest channel. Choose the audience based on the work. A design decision belongs with the teams affected. A release result belongs in the project update. A career mapping belongs in a development conversation.
Use a short update: what changed, your role, who contributed, the evidence, and any next step. If the reader needs to act, state the request. If the update is simply closing a loop, say what was resolved. Useful communication earns attention by reducing someone else’s uncertainty.
When someone praises your work, accept the recognition without erasing the team: “Thank you. I’m glad the rollback check helped. Priya’s test cases were important to getting it right.” You do not need to correct every compliment into a disclaimer about your own contribution.
Ask collaborators for specific feedback
Instead of “Can you say something nice for my review?”, ask, “What did my contribution change for your team, and is there anything I should improve next time?” This invites useful feedback and gives the other person room to disagree.
If you quote feedback, preserve its meaning and context. Do not turn “helpful during this rollout” into evidence of broad organizational leadership. Get permission where appropriate before sharing beyond the original audience, and keep sensitive details out of public career material.
Handle attribution disagreements calmly
If a collaborator sees the division of work differently, return to the artifacts and responsibilities. You may discover that you are describing different parts of the same project. Revise the record so it reflects the shared understanding.
If the disagreement remains important, discuss it with your manager using concrete examples. Avoid converting the issue into a public contest over credit. The immediate objective is an accurate record and clearer responsibility on future work.
- Name the team outcome first when it is shared.
- Use a specific verb for your own role.
- Identify collaborators and their ownership.
- Attach evidence for the claimed change.
- Choose an audience that needs the information.
- Keep feedback in its original scope.
Use this approach in your self-review and your promotion conversation. The record format in The Promotion Packet, by Hand gives you a place to preserve attribution before memory blurs it.
Written for Worktold using public sources and original illustrative examples. Product research checked November 10, 2026. Read our editorial approach and comparison limits.
