Write clear emails and documents, present and run meetings, work well on teams, and navigate résumés, interviews and networking.

Professional Communication & Teamwork

Write a one-sentence description of the project and its deadline.

List every person and their role, so each main task has exactly one owner. Note who decides scope and who decides how the work is done.

Draft 5-7 specific norms covering communication channels and reply times, meetings, how decisions are recorded, what "done" means, and how to raise a problem.

Share the draft with the team and ask each person to suggest one change. (Alone: review it as each role in turn and ask what that person would want changed.)

Agree the final list and put it where everyone can see it, such as the top of the shared doc or task board.

Set a date, about two weeks out, to review the norms and change any that are not working.

## 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:

```text
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:

```text
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.


Make roles clear, build trust, and agree written team norms for a small project.

Roles, trust, and collaboration

What Is Psychological Safety?

Setting team norms that stick  |  vivovii and Corentus

## Why it matters

Disagreement is normal on any team that cares about its work. Two engineers may want different designs. A tester may think a release is not ready while a manager wants to ship. A lab supervisor and a technician may disagree about whether a result needs a rerun. Handled well, disagreement leads to better decisions. Handled badly, it turns into resentment, silence and people working around each other.

The goal is not to avoid conflict. It is to keep the disagreement about the problem, not about the people.

## Task conflict and relationship conflict

It helps to separate two kinds of conflict:

- **Task conflict** is about the work: which approach, which priority, which deadline. It is often healthy, because it brings out different information.
- **Relationship conflict** is about people: feeling disrespected, ignored or blamed. It almost always hurts the team.

Task conflict turns into relationship conflict when people feel unheard. That is why listening is the most important de-escalation skill.

## The core idea: active listening

Active listening means trying to fully understand the other person before you respond. It is different from waiting for your turn to talk. It has four parts:

1. **Give full attention.** Stop typing, put your phone away, look at the person (or the camera).
2. **Reflect back** what you heard in your own words: "So your concern is that if we ship Friday, the reporting bug will reach customers."
3. **Ask open questions** that start with "what" or "how": "What would you need to feel comfortable shipping?" Avoid "why" questions in a tense moment, which can sound like accusations.
4. **Name the feeling, carefully**, when it helps: "It sounds like you're frustrated that this keeps happening." Then check: "Is that right?"

When people feel understood, they calm down. Only then can you solve the problem together.

## A process for de-escalating

When a disagreement gets heated, slow it down:

1. **Pause and lower the temperature.** Speak slowly. If emotions are high, suggest a short break: "Can we take ten minutes and come back to this?"
2. **Move to a private setting** if the conversation started in front of others or in a public chat channel.
3. **Listen first**, using the four steps above, until the other person agrees you have understood them.
4. **Share your view** using "I" statements and facts: "I'm worried about the deadline because the client demo is on Monday."
5. **Find the shared goal.** Usually both people want the same thing (a working product, accurate results, a safe site) and disagree on how to get there.
6. **Look at options together**, including ones neither person started with.
7. **Agree on a next step**, and write it down.

## Worked example

Two developers disagree in a pull request about whether to rewrite a module. The thread is getting sharp.

Escalating reply:

```text
This rewrite is a waste of time. The current code works fine and you
just want to use your favourite library.
```

De-escalating reply:

```text
I think we see this differently, so let me check I understand your
view. You want to rewrite the module because the current code is hard
to test and caused two bugs last month. Is that right?

My concern is the timeline: the release is in two weeks and the
rewrite touches billing. Could we talk for 15 minutes today? One
option might be to add tests around the current code now and plan the
rewrite for next sprint.
```

The second reply reflects the other person's view, explains a concern with facts, moves the discussion to a call and offers an option. It does not decide who is right. It makes it possible to decide together.

## When you can't agree

Sometimes, after listening and discussing, you still disagree. That is fine. Options include:

- **Use your team's decision rules.** If a tech lead or project lead decides, ask them to make the call with both views on the table.
- **Disagree and commit.** Say clearly that you disagree, then fully support the decision once it is made.
- **Run a small test** if the question can be settled with data, such as a prototype, a benchmark or a pilot.
- **Escalate respectfully** if the issue involves safety, ethics, harassment or a legal rule. These are not matters for a compromise. Raise them with your manager, HR or the appropriate safety or compliance contact, following your organization's policy.

## Common mistakes

- **Arguing in public channels** where everyone feels they must take sides.
- **Interrupting** or preparing your reply while the other person talks.
- **Making it personal**: "you always", "you never", comments about character.
- **Avoiding the conversation** until the problem is much bigger.
- **Winning the argument but losing the colleague.**

## Quick recap

- Keep conflict about the task, not the person.
- Active listening: attention, reflect back, open questions, name feelings carefully.
- Slow down, go private, listen first, find the shared goal, agree a next step.
- If you still disagree, use the team's decision rules, then commit; escalate safety and conduct issues.

## Try it

This lesson has no activity. Take the quiz on the Do tab to check your understanding of de-escalation and active listening.


De-escalate a workplace disagreement by listening first and focusing on the shared goal.

Handling disagreement

The Art of Active Listening | The Harvard Business Review Guide

Conflict Resolution in the Workplace: 5 Strategies | Business: Explained

Write a status update with three headings: Done, Next, Blockers.

Make each Done item a result, not an activity ("the table works" rather than "worked on the table"), and add a link or reference where possible.

For each blocker, name who can help, what you need from them and by when. If there are no blockers, write "None".

Write a handoff note for the same task with: context, current state, numbered next steps, things to watch out for, links, and who to ask.

Read the handoff note as if you had never seen the task. Mark every place you would need to ask a question, and fill in the missing details.

If you can, give the handoff note to someone else and ask whether they could continue the work without messaging you.

## Why it matters

Many technical teams now work partly or fully remotely, and even office-based teams spread across sites, shifts and time zones. When you cannot tap someone on the shoulder, writing becomes the main way work moves forward. Two skills matter most: **async status updates** that keep people informed without a meeting, and **handoff notes** that let someone else pick up your work.

## Sync and async

- **Synchronous (sync)** communication happens at the same time: meetings, calls, live chat.
- **Asynchronous (async)** communication lets people respond when it suits them: email, documents, tickets, chat messages that do not need an instant reply.

Async work lets people focus for long stretches and works across time zones. Its weakness is delay: a vague message can cost a full day of back-and-forth when the reply comes from the other side of the world. So async messages must be complete enough to act on without a follow-up.

Use sync for sensitive conversations, complex disagreements and brainstorming. Use async for updates, questions that can wait and decisions that need time to think.

## Writing for async

A good async message:

- **Stands alone.** Include links, versions, screenshots and error messages, so the reader does not need to ask "which one?".
- **States what you need and by when**, or says clearly that no action is needed.
- **Asks complete questions.** Not "Hi, are you there?" followed by a wait, but the whole question in one message.
- **Uses the right channel**: tickets for tasks, chat for quick questions, documents for decisions.

## Async status updates

A common format is a short daily or weekly update with three parts:

1. **Done**: what you finished since the last update.
2. **Next**: what you plan to do next.
3. **Blockers**: anything stopping you, and who can help.

Add links so people can see details if they want. Example:

```text
Status: Sam, Tue 2026-10-14

Done
- Finished the CSV import for supplier data (PR #318, merged).
- Fixed the date-parsing bug for DD/MM files (ticket INV-92).

Next
- Start the export screen (INV-95). Aim: draft PR by Thursday.

Blockers
- Need read access to the staging database to test imports with
  real-size files. @Priya, could you grant it today or tomorrow?
```

Notice the blocker names a person, a specific request and a time. A blocker without an owner is just a complaint.

## Handoff notes

A handoff happens when work passes to someone else: at the end of a shift, before a holiday, when you change projects or when a teammate in another time zone continues your task. Lab shifts, on-call rotations and site work depend on good handoffs; a missing detail can mean repeated work or a safety risk.

A handoff note covers:

- **Context**: what the task is and why it matters.
- **Current state**: what is done, what is in progress, what is not started.
- **Next steps**, in order.
- **Watch out for**: known risks, quirks, deadlines.
- **Where things are**: links to code, documents, samples, logs.
- **Who to ask** if something is unclear, and when you will be back.

Example:

```text
Handoff: supplier import feature (Sam -> Alex), from Fri 10-17

Context: suppliers upload a CSV of prices; we import it nightly.
Client demo on Wed 10-22.

State
- Import: done and merged (PR #318).
- Export screen: about 60% done on branch export-screen. Table works;
  the download button is not wired up yet.

Next steps
1. Wire the download button to /api/export (see TODO in Export.tsx).
2. Add a test for an empty export.
3. Open the PR and ask Priya to review.

Watch out
- Files over 5 MB time out on staging; production is fine.
- The demo uses supplier "Acme Test". Don't delete it.

Links: board ticket INV-95, design doc, staging URL.
Questions: Priya (tech lead). I'm back Mon 10-27.
```

A good test: could your colleague continue the work without messaging you at all?

## Remote habits that build trust

- **Be visible.** Post updates regularly, even short ones. Silence makes people wonder.
- **Share your working hours and time zone**, and respect other people's.
- **Turn on your camera when it helps**, for example in introductions and difficult conversations, if your team does that.
- **Write down decisions** made in calls and post them where the team can find them.
- **Over-communicate early in a new team**, then adjust.

## Common mistakes

- **"Hi" messages** with the question coming later.
- **Updates that list activity, not progress**: "worked on the export" instead of "the table works; the button is left".
- **Blockers with no owner** or no request.
- **Handoffs that assume context** the other person does not have.
- **Decisions made in a call** and never written down.

## Quick recap

- Async messages must stand alone: context, links, the ask and a deadline.
- Status updates: done, next, blockers (with an owner).
- Handoff notes: context, state, next steps, risks, links, contacts.
- Write decisions down and keep your teammates informed.

## Try it

Open the Do tab. You will write an async status update and a handoff note for a real or practice task.


Write async status updates and handoff notes that let others act without a meeting.

Remote and async work

How to Collaborate Effectively If Your Team Is Remote (The Explainer)

What is Asynchronous Communication in Remote Work? (Why It's Important)

Set roles and team norms, build trust, handle disagreement with active listening, and work well remotely and asynchronously.