Roles, trust, and collaboration

Why it matters

Almost no STEM work is done alone. A software feature involves developers, a designer, a tester and a product owner. A lab result involves the technician, the reviewer and the quality team. A building project involves engineers, electricians, inspectors and the client. Hiring managers often say teamwork and communication separate good candidates from great ones, because a talented person who is hard to work with slows the whole team down.

Good teamwork is not about everyone being friends. It is about clear roles, reliable habits and enough trust that people speak up about problems early.

Roles: who does what

Many team problems are really role problems: two people do the same task, or nobody does it because each assumed the other would. Make roles explicit at the start of any project.

A simple way is a short responsibility list:

Project: student club website (4 weeks)

Aisha  - project lead: plans the work, runs the weekly check-in,
         talks to the club committee
Ben    - front-end: pages and styling
Chloe  - content: text, photos, event calendar
Dev    - testing and deploy: checks every page on phone and laptop,
         publishes the site

Decisions about scope: Aisha, after asking the committee.
Decisions about how to build it: Ben and Dev together.

Larger organizations use tools like a RACI chart (who is Responsible, Accountable, Consulted and Informed for each task). The tool matters less than the habit: every task has exactly one owner, and everyone knows who decides what.

Trust: the foundation

Research at Google on what makes teams effective (Project Aristotle) found that the most important factor was psychological safety: team members feel safe to take risks, ask questions and admit mistakes without being embarrassed or punished. Harvard professor Amy Edmondson, who developed the idea, showed that teams with more psychological safety report more of their errors, which lets them fix problems early.

You build trust through small, repeated actions:

• Do what you said you would, by when you said. If you cannot, say so early.
• Admit mistakes quickly. "I pushed a bug in yesterday's release. Here's what happened and how I'm fixing it."
• Ask questions openly. If you do not understand something, others probably do not either.
• Give credit to the people who did the work.
• Assume good intent when something goes wrong, and ask before blaming.

Team norms: agreeing how you work

Norms are the team's shared rules about how to work together. Every team has them; the question is whether they are agreed or just assumed. Unspoken norms cause friction: one person expects replies within an hour, another checks messages once a day.

At the start of a project, spend 20 minutes agreeing a short list. Good norms are specific and cover:

• Communication: which channel for what, and how fast to reply.
• Meetings: when, how long, and who takes notes.
• Decisions: how they are made and where they are recorded.
• Quality: what "done" means (tested? reviewed? documented?).
• Problems: how to raise a concern or a disagreement.

Example:

Team norms: club website project

1. Chat is for quick questions; reply within one working day.
   Urgent = call or @mention with "URGENT".
2. Weekly check-in Mondays 18:00, 20 minutes, notes in the shared doc.
3. Every task lives on the board with one owner and a due date.
4. "Done" = works on phone and laptop, and someone else has looked at it.
5. If you will miss a deadline, say so at least a day before.
6. Disagree in the meeting or directly, not behind someone's back.
7. We review these norms after week 2.

Write them down where everyone can see them, and revisit them. Norms that are never checked fade within weeks.

Collaboration habits that help

• Make work visible. Use a shared task board so everyone can see what is in progress, blocked or done.
• Share early drafts. A rough version shown on day 2 is easier to change than a polished one on day 10.
• Ask for help when blocked. A good rule is to try on your own for a set time (say 30–60 minutes), then ask, explaining what you tried.
• Hand off cleanly. When you pass work to someone, say what is done, what is left and where things are.
• Respect differences. Teams with different backgrounds, time zones and working styles solve problems better, but only if everyone's input is invited.

Common mistakes

• Assuming roles are obvious, so tasks fall through the cracks.
• Silent struggling: hiding problems until the deadline.
• Over-promising and quietly missing commitments.
• Norms that live only in one person's head.
• Credit hoarding or blaming individuals for team failures.

Quick recap

• Give every task one owner and make decision rights clear.
• Psychological safety lets teams surface problems early; build it with reliability, honesty and credit.
• Agree specific, written team norms and review them.
• Make work visible, share drafts early and ask for help when blocked.

Try it

Open the Do tab. You will agree a set of team norms for a small project, with real teammates if possible.