Was it me or the team? How to describe your own contribution in a portfolio honestly

Most valuable products, campaigns, implementations and processes are created by teams.

Showing the final result alone does not tell us what role a particular specialist actually played.

For someone reviewing a portfolio, the difference is substantial:

"I worked on redesigning the checkout process"

is not the same as:

"I led the research, designed the new checkout flow, prepared the prototype and ran usability tests. A separate frontend engineering team handled the implementation."

The second description makes it possible to assess real competence without diminishing the work of other people.

This problem is not unique to professional portfolios.

In scholarly publishing, one example is CRediT - Contributor Role Taxonomy. The standard describes 14 contributor roles and was created to improve transparency about who was actually responsible for different parts of a work. CRediT allows one person to have multiple roles and one role to be shared by multiple people. It also recommends that contributors have an opportunity to review and confirm the roles attributed to them. [1]

CRediT is primarily intended for research and scholarly publishing. It is not a professional portfolio standard. It does, however, demonstrate a useful principle that can be applied more broadly: instead of relying on the vague statement "I was part of the project", clearly state the type of contribution you actually made.

A good team-project description can be built around six pieces of information:

1. Project context
2. Team composition and scope
3. Your own responsibility
4. Specific actions and decisions
5. Work artifacts or evidence
6. The result and how it is attributed

The goal is not to produce a long report. The goal is to remove the most important ambiguities.

First explain what the team was actually working on.

A short description is enough:

• the problem or objective,
• the type of product or service,
• the approximate scale,
• important constraints,
• the delivery period, if relevant.

Example:

The goal was to shorten the purchasing process in a B2B application. The product operated in several European markets and served business customers.

This gives the reader enough context before they assess an individual's contribution.

You do not need to list every person by name.

In many cases, a simple structure is enough:

Team: product manager, user-experience designer, 2 frontend engineers, 2 backend engineers and a quality specialist.

This single piece of information changes how the entire project description is interpreted.

The reader can see that the outcome did not appear in isolation and that the specialist worked within a defined distribution of responsibilities.

This is the most important part.

Instead of the vague:

"I worked on the frontend"

write something specific:

"I was responsible for the payment-module architecture, implementation of the checkout process, integration with the payment API and code review for changes in this area."

It can also be useful to state what you did not do when that might otherwise be unclear:

"A separate team handled the server-side layer and the server-side payment-provider integration."

This does not weaken the portfolio. It makes it more credible.

A job title is not yet a description of contribution.

A senior user-experience designer may lead the entire research process in one project and prepare only final screens in another.

Show actions that can be connected to specific capabilities:

• I designed the solution architecture,
• I conducted research,
• I designed the process flow,
• I analysed the data,
• I wrote a key part of the implementation,
• I prepared the campaign strategy,
• I led negotiations,
• I coordinated dependencies between teams,
• I verified the solution before release.

The most useful examples are those where you can also explain why a particular decision was made.

If the project can be shown, an artifact helps connect the claimed contribution with real work.

For example:

• a product screen,
• part of an interface,
• a prototype,
• a code excerpt,
• a public repository,
• a report,
• a diagram,
• a publication,
• campaign material,
• a photograph,
• a document or a safe excerpt from one.

An artifact does not have to prove everything. Its purpose is to help the reader understand what was actually created and how it relates to the contribution being described.

The greatest risk of overstating personal contribution appears when describing results.

If a company's conversion rate increased by 25% after a project, that does not automatically mean one person increased conversion by 25%.

During the same period, many other factors may have changed:

• prices,
• the offer,
• marketing,
• user experience,
• infrastructure,
• seasonality,
• traffic sources,
• the work of other team members.

Describe the result with only the level of certainty you can genuinely justify.

1. Direct responsibility
"I reduced the time required for this process from 12 to 4 minutes by automating the steps I was responsible for."

Use this when the link between your own action and the outcome is direct and can be justified.

2. Shared result
"Together with the team, we redesigned the user onboarding process. After release, the completion rate increased by 18%."

Use this when the result was created through the work of several people.

3. Contribution to a broader change
"I was responsible for redesigning the checkout process as part of a wider optimisation of the purchasing journey. After the full programme was released, the company recorded an increase in conversion."

Use this when your area was only one of several contributing factors.

4. Result as project context
"The project ended with a 40% increase in sales. My scope covered client-side architecture and implementation of the checkout process."

Use this when you know the overall project result but do not have a sound basis for determining how much of it was caused by your work.

When a project features several people, the best description should answer two questions at the same time:

What did the team deliver?

and

What was each person responsible for?

Example:

Project: first version of a logistics application
Team: user-experience designer, frontend engineer, backend engineer
Shared result: a working first product version prepared for a pilot
User-experience designer: research, user journey, prototype, interface design
Frontend engineer: client-side architecture, implementation of the web application
Backend engineer: API, data model, integrations

This kind of project description strengthens both the team and the individual specialists.

In some projects, simple descriptions of involvement are useful:

Lead role - I led the area and was responsible for key decisions.
Shared responsibility - I shared responsibility with one or more other people.
Supporting role - I supported the area but was not its primary owner.

CRediT uses a similar distinction for contributor roles. [1]

The key principle is simple: the level of responsibility should be understandable.

For important shared projects, it is worth checking that your description of your own contribution does not clearly conflict with how other participants understand the roles.

CRediT recommends that contributors have an opportunity to review and confirm the roles attributed to them. [1]

In a professional portfolio, this does not have to mean a formal approval process for every sentence. The practical rule is simpler: do not claim responsibility for work that was actually led by someone else.

Describing your own contribution should not be confused with determining copyright ownership.

Under Polish copyright law, copyright generally belongs to the author, and co-authors hold it jointly. For works created in the course of employment, an employer may acquire economic copyright within the scope defined by the law and the employment relationship. [2]

In practice, treat these three questions separately:

Did I take part in creating the project?
Am I the author or co-author of a particular element?
Do I have the right to publish the material in my portfolio?

A "yes" to the first question does not automatically determine the answers to the other two.

Not every project can be shown or described in detail.

Polish unfair-competition law protects information that constitutes a trade secret, including certain technical, technological, organisational and other information with economic value that is kept confidential. [3]

For a confidential project, simply removing the client's name may therefore be insufficient. The remaining details may still reveal protected information.

A safer rule is:

describe only what you are actually permitted to disclose under applicable law, contracts, consents and other rights you hold.

A project description usually does not need private data about the entire team.

The GDPR requires, among other things, lawfulness, purpose limitation and data minimisation, meaning that personal data should be limited to what is necessary for the relevant purpose. [4]

If the team can be described as:

1 user-experience designer, 2 frontend engineers, a backend engineer and a quality specialist

there is no automatic need to publish colleagues' names, photographs, email addresses or other personal data.

If you want to publish a testimonial, statement, image or other data relating to a specific person, check the appropriate legal basis and the scope in which the material may be used.

If the terms of your cooperation permit a general description of the experience, you may consider showing:

• the type of problem without identifying the client,
• your own role,
• categories of skills used,
• the type of responsibility,
• the decision-making process at an appropriately general level,
• the result only to the extent that it may be disclosed.

Do not invent screenshots, data or results to replace material that is confidential.

If you are unsure whether a particular piece of information may be disclosed, it is safer not to publish it until the issue has been clarified.

Small differences in wording can communicate the level of responsibility very clearly.

I was responsible for... - clearly identifies your own area.
I led... - indicates responsibility for the direction or delivery of a particular scope.
I co-created... - shows that the result had more than one author.
I supported... - accurately describes a supporting contribution.
I was part of the team that... - separates individual participation from the team's overall result.
After the project was released, the company recorded... - presents the result as context without automatically claiming the whole effect as your own.

Avoid automatically saying "I did it" when the real scope was shared.

1. You use the singular for a project delivered by many people.

2. You show a business result without explaining your own scope.

3. You list technologies from the entire product as your own skills even though you did not work with all of them.

4. You show the final visual design, code or strategy without explaining which parts you actually created.

5. You omit key contributors where their involvement is necessary to understand the project.

6. You imply a causal link between your work and a result that you cannot substantiate.

Project
What was being created and what problem was it intended to solve?

Team
Which roles took part in the project?

My responsibility
Which area was I personally responsible for?

My actions and decisions
What did I actually do or lead?

Collaboration
Which elements were created jointly with other people?

Artifacts
What am I legally allowed to show?

Result
What did the project achieve, and how did my contribution relate to that result?

Constraints
Are there elements I cannot disclose because of confidentiality or other people's rights?

Ask yourself seven questions:

1. Does the reader know how large the team was?

2. Is it clear exactly what I was responsible for?

3. Have I avoided claiming work performed by other people?

4. Is the result described with an appropriate level of caution?

5. Am I legally allowed to publish the materials used?

6. Am I avoiding unnecessary disclosure of personal or confidential information?

7. Could an outside reader tell from this description which skills I actually used?

If the answers are clear, the project description starts working as evidence of competence rather than just an attractive story.

The best project description does not have to choose between:

"I did this"

and

"the team did this."

It can show both truths at the same time:

the team delivered a specific result, and I was responsible for a specific part, decisions and execution.

That level of precision makes it possible to assess a specialist without taking credit away from everyone else.

A portfolio should not be a competition for the biggest possible claim.

Its value increases when the person on the other side can understand:

what was created, who worked on it, what you were responsible for, what you personally did and what result can reasonably be connected to your contribution.

A precise description does not weaken an achievement.

On the contrary, it shows that you understand your own responsibility, can work with others and can represent the results of your work honestly.

[1] CRediT - Contributor Role Taxonomy, NISO
Open the source

[2] Polish Act on Copyright and Related Rights - Articles 8-12, ELI
Open the source

[3] Polish Act on Combating Unfair Competition - Article 11, consolidated text published in 2026
Open the source

[4] Regulation (EU) 2016/679 - GDPR, Article 5, EUR-Lex
Open the source

Methodological note: CRediT is a standard for contributor roles in research and scholarly publishing. This article uses it as an example of transparent contribution attribution, but does not present it as a professional portfolio standard. The six elements of a project description and the four ways of describing a relationship to results are an editorial model proposed in this material.