How to work as a team on creative and tech projects without ending up doing everything yourself

When your way of working can no longer be handled by just one person

Up until now, you’ve been able to control the entire process: you research, decide, produce, revise and deliver. It works. But in a collaborative project, that continuity is broken. Someone else prepares the content you need. Someone else programmes the interaction of your interface. The 3D model has to be adapted to an engine. The prototype depends on materials and manufacturing. The data has to be received before a model can be trained.

The difficulty isn’t just about trusting others. It’s that your work is no longer self-contained.

If you’re used to doing everything on your own, the change isn’t just about delegating. It’s about making your process understandable so that someone else can continue, review or integrate what you’ve done. Real collaborative work is learnt through structure, not just good will.

Before opening a folder, draw up a one-page team agreement

The most common mistake when organising a team project is to start straight away with the tools. First, you need to answer twelve questions that will prevent most of the friction that might arise later.

The minimum agreement

1. Deliverable: exactly what is to be delivered.
2. Scope: what is included and what is excluded.
3. Responsibilities: who is accountable for each part.
4. Decisions: who makes the final call in the event of a disagreement.
5. Prerequisites: what each person needs to move forward.
6. Internal deadlines: when each part must be ready for review.
7. Files: where the valid version is stored.
8. Channels: where discussions take place.
9. Reviews: when and how feedback is provided.
10. Blockers: how long an issue can remain unresolved without being reported.
11. Absences: how to give notice and how to reallocate work.
12. Delivery: who integrates, checks and presents.

A team agreement does not eliminate conflicts. It prevents each conflict from having to invent its own rules.

Simply dividing up tasks isn’t enough: each part needs someone in charge and the ability to make decisions

Knowing how to allocate tasks within a group is one of the first questions any team faces, but the division of labour only works when each part has a clear role. It is not the same to simply take part as it is to be accountable for the outcome.

Roles within a project can be combined — one person may be responsible for one part and act as a reviewer for another — but the team needs to know who is performing each role for each deliverable.

Responsibility without decision-making power leads to frustration. Decision-making without responsibility leads to arbitrariness.

Make the work visible before it becomes urgent

Every task in the project must show what needs to be done, who is responsible, what its status is, what its internal deadline is, what it depends on, whether there are any blockers, and what it means for the task to be completed.

You can organise this using a board, a shared spreadsheet, a task manager, a repository or a simple combination of these. The tool itself isn’t important. What matters is that the work no longer exists solely in the minds of individual team members.

Minimum statuses for each task

Pending → In progress → Under review → Blocked → Completed.

That’s it. Too many categories take up more time than they save.

A task that nobody can see cannot be co-ordinated.

An orphaned file is also a source of conflict

Managing shared files is one of the areas where most projects fall apart. When ten versions of the same file exist in emails, local downloads and chat conversations, the end result is built on sand.

Minimal folder structure

00_BRIEF_AND_REFERENCES
01_WORK_IN_PROGRESS
02_REVIEW
03_APPROVED
04_EXPORTS
05_FINAL_DELIVERY

Guideline for naming conventions

project_piece_status_date_initials_v01

The team chooses the naming convention, but once decided, it is adhered to.

Depending on the discipline, files present different challenges. In software development, version control allows changes to be tracked and work to be merged. In design, a distinction must be made between the editable file and the final export. In audiovisual work, codecs, resolutions and file names must be agreed upon. In 3D, textures, materials and scene versions. In data, datasets, transformations and results.

There must be only one recognised source for the project. Email, chat or a local download must not become the master file.

Meetings should finalise decisions, not replace the work

Distinguish between three types of meeting and do not mix them up:

Kick-off meeting: define the deliverable, allocate roles, identify dependencies, agree on tools and set review dates.

Brief update: each person reports on what progress they’ve made, what they’ll do next, what they need from the team and what’s holding them back.

Review: assess a specific deliverable against agreed criteria.

To truly coordinate a project, every meeting needs an objective, a person in charge and an expected decision. Without these three elements, the meeting merely turns disorganisation into a collective activity.

Reporting a roadblock is not an admission of failure

Many students hide roadblocks because they fear appearing slow, causing a nuisance or losing control over their part of the work. But a roadblock communicated in good time is useful information. A roadblock hidden until the deadline becomes a risk for everyone.

Template for reporting a roadblock

• I’m trying to achieve…
• I have tried…
• The specific problem is…
• This affects…
• I need the team to…
• I need to sort this out before…

Example:  “I can’t get the model to import without losing the materials. I’ve checked the export settings and paths, but it’s still failing. This is preventing the scene from being lit. I need us to go through the format together before Wednesday.”

Feedback should improve the project, not decide who is right

Phrases such as “I’m not convinced”, “I’d do it differently” or “make it more creative” do nothing to help improve the work. Useful feedback follows a structure:

1. Observation: what can be seen or what is happening.
2. Effect: what problem it causes.
3. Criterion: which objective or agreement it conflicts with.
4. Question or suggestion: what could be reviewed.

Example:  “The menu hierarchy makes the secondary action stand out more than the primary one. This may confuse the user and contradicts the agreed flow. Could we try a version where the primary action has greater visual weight?”

The work is reviewed according to shared criteria. The person who created it is not evaluated.

Not all conflicts within teams are resolved in the same way

Conflict does not mean the team has failed. Conflict without rules, accountability or dialogue, however, can lead to failure.

What to do when someone fails to deliver their part

Don’t redo it in silence, and don’t wait until the last minute to point it out. The sequence is:

1. Confirm that the expectation was clear.
2. Ask what is preventing progress.
3. Check whether the task was realistic.
4. Agree on a specific interim deadline.
5. Reallocate if there is an objective risk.
6. Record the change.
7. Inform the teacher or person in charge if the non-compliance persists.

The aim is not to punish. It is to protect the project and highlight each person’s contribution.

The trap of always having to bail out the project

If you always end up redoing other people’s work, perhaps the problem isn’t your team. Those who constantly bail others out hide systemic problems, prevent others from learning, build up resentment and become a bottleneck.

Alternatives: define the standard beforehand, ask for partial deliverables, review early, offer guidance rather than finished solutions, pair up people with complementary skills, and accept that a shared solution won’t always be identical to the one you would have created on your own.

Helping does not mean silently taking on someone else’s responsibility. A team does not learn to work better when one person secretly makes up for everything that goes wrong.

“We’ll put it all together later” is one of the riskiest decisions in a project

Each person may produce a correct part that doesn’t fit with the others: an interface that doesn’t take technical limitations into account, a 3D model that’s too heavy for the environment, an animation that doesn’t adhere to the editing format, or a prototype that can’t be manufactured as depicted.

Before handing over any deliverable, specify what it contains, what is finished, what remains to be done, how to open it, which version it is, what dependencies it has, and what the next person needs to check.

An internal handover isn’t just about dropping off a file. It’s about enabling the next person to continue the project without having to recreate your workflow.

Before handing over, review the project as a whole

It is not enough to review each part separately. Check for consistency, functionality, tone, formats, names, links, fonts, accessibility, spelling and requirements.

Three final tasks that must be assigned

1. Integration: brings together and connects all the parts.
2. Quality control: checks criteria and requirements.
3. Presentation or handover: ensures it is sent or presented correctly.

These roles may be combined, but they must be clearly defined before the final day.

The project ends; the team’s learning shouldn’t end with it

Spend fifteen minutes on a brief retrospective:

• What helped us make progress?
• Where did we waste time?
• Which dependency did we spot too late?
• What agreement was missing?
• Which decision worked?
• What would we change in the next team?

Finish with two lists: three things to keep and three things to change. Nothing else.

Teamwork varies from project to project, but the friction is similar

In creative and technological projects, each discipline creates different dependencies. These are the most common:

The more interdisciplinary a project is, the less it can rely on each person doing their part well in isolation.

If a university claims to use a project-based approach, ask how it organises its teams

When comparing degree programmes, take these questions with you to the open day, the admissions interview or your campus visit:

1. From which year do group projects begin?
2. How are the teams formed?
3. Are students from different backgrounds or degree programmes mixed together?
4. How are roles allocated?
5. What collaboration tools are used?
6. How is individual contribution recorded?
7. Is only the outcome assessed, or is the process assessed as well?
8. What happens if someone doesn’t take part?
9. Do the projects have interim deliverables?
10. Who compiles the final work?
11. How do teachers intervene in the event of a conflict?
12. Can we see complete examples of the process, not just the final result?

Quick checklist: does your project meet the minimum requirements?

• [ ] Are we all describing the same outcome?
• [ ] Is there a designated person responsible for each task?
• [ ] Do we know who makes the decision in the event of a disagreement?
• [ ] Is there a single valid version of each file?
• [ ] Are dependencies clearly visible?
• [ ] Are there review dates prior to handover?
• [ ] Are blockers communicated in a clear format?
• [ ] Has integration been assigned?
• [ ] Do we know what ‘completed’ means?
• [ ] Is the workload reasonably balanced?

If more than three answers are ‘no’, the project carries more risk than necessary.

Frequently asked questions

How can I work as part of a team if I’m used to doing everything on my own?

Start by making your process transparent. Agree on the outcome, who’s responsible, the decisions to be made, internal deadlines and where the files will be stored. Don’t wait for a problem to arise before explaining how you work. Collaboration improves when others can understand what you need, what you’re doing and when they should step in.

How should tasks in a project be allocated?

It’s not enough simply to divide the work equally. You need to consider skills, workload, dependencies and accountability. Each task needs a designated person in charge, even if several people are collaborating on it. It must also be clear who reviews the work and who makes the final decision if there are conflicting proposals.

What roles does a creative team need?

At the very least, each deliverable must have a person in charge, designated collaborators, someone to review it and a person with the authority to finalise decisions. The project also needs people responsible for coordination, integration and delivery, although in small teams one person may take on several roles.

How should files be organised for group work?

Use a single space recognised as the authoritative source, a clear folder structure and a common convention for naming versions. Separate editable files, materials under review, approved versions and final exports. Ensure the master file is not stored solely on a single computer, in an email or in a private conversation.

What should I do if a team member fails to deliver their part?

First, check that the responsibility, deadline and expected standard were clear. Ask what is holding up the task, agree on an interim deadline and reassign the task only if there is a genuine risk. If the failure to comply continues, document the agreements and report it to the teacher or supervisor before the deadline, not after.

How do you give feedback without causing conflict?

Describe what you observe, the effect it has, and the criteria against which it falls short. Then put forward a question or suggestion. Avoid turning a personal preference into a rule. Feedback should assess the work against shared criteria, not judge the ability or attitude of the person who produced it.

How can you tell if a university really teaches students to work in teams?

Ask how groups are formed, how roles are assigned, what tools are used, how individual contributions are recorded, whether there are interim reviews, and what happens when a conflict arises. It’s also worth asking for examples of the entire project process, not just images of the final result.

When comparing degree programmes, don’t focus solely on the outcome of the projects. Ask how teams are formed, how responsibilities are allocated, how the work is assessed, and what tools are used to integrate different disciplines. That’s also where you learn to design, programme, create and build professionally.