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 down, in one sentence, exactly what you need, from whom and by when.

Write a subject line that states the request and the deadline, in 10 words or fewer.

Write the first two sentences of the email so they contain the full ask and the deadline.

Add only the context the reader needs to say yes or no, as 2-4 bullet points.

Add a close that makes the next step obvious (for example, an alternative if the first option is not possible).

Run the before-you-send checklist: recipients, attachments and links, names, dates and numbers. Read it once out loud.

Ask a friend to read only the subject line and first two sentences, then tell you what you want. Fix anything they got wrong.

If the request is real, send it. Otherwise save it as a template for later.

## Why it matters

In almost every STEM job, a lot of the work happens over email. You ask a lab manager for instrument time. You ask a senior developer to review your code. You tell a client a part will arrive late. A clear email gets a fast answer. A vague one gets ignored, or it starts a long thread of back-and-forth questions.

The good news is that a useful work email follows a pattern you can learn in an afternoon. You do not need fancy vocabulary. You need to make the reader's job easy.

## The core idea: lead with the ask

Busy people read the subject line and the first two sentences, then decide whether to deal with the message now, later or never. So put the most important thing first.

A request email has five parts:

1. **A specific subject line.** Say what you need and by when, if there is a deadline.
2. **A short greeting.** Use the person's name. "Hi Priya," is fine in most workplaces.
3. **The ask, in one or two sentences.** What do you need, from whom, and by when?
4. **The context the reader needs to act.** Only the facts that help them say yes or no. Use bullet points for more than two items.
5. **A clear close.** Thank them, and make the next step obvious.

Think of it as "bottom line up front". The reader should know what you want even if they stop reading after the first paragraph.

## Worked example

Here is a first draft from a new lab technician:

```text
Subject: Question

Hi,

I hope you are doing well. I wanted to reach out because I have been
working on the stability samples and I noticed that the HPLC schedule
looks pretty full this week and I was wondering if there was any
possibility of maybe getting some time on it at some point, because
the samples need to be run soon. Let me know what you think.

Thanks
```

The reader has to work out what is being asked, how much time is needed and how urgent it is. Here is the rewrite:

```text
Subject: Request: 2 hours on HPLC-2 before Thursday noon

Hi Priya,

Could I book 2 hours on HPLC-2 before Thursday at noon? The schedule
shows it is full, so I wanted to ask you directly.

Context:
- 12 stability samples (batch 4417) reach their 30-day pull on Thursday.
- They must be injected within 24 hours of the pull.
- Any slot Wednesday afternoon or Thursday morning works for me.

If HPLC-2 is not possible, is HPLC-1 free? I can adjust the method.

Thanks,
Sam
```

The second version is not much longer, but it is far easier to answer. Priya can reply with a single line: "Wednesday 2–4 pm is yours."

The same pattern works in software. Compare "Can you look at my PR?" with:

```text
Subject: Review needed by Friday: PR #212 (password reset fix)

Hi Marco,

Could you review PR #212 by end of day Friday? It fixes the bug where
reset links expired after 5 minutes instead of 24 hours.

- 3 files changed, about 60 lines.
- Tests added for the expiry check.
- The part I am least sure about is the timezone handling in expiry.js.

Thanks!
Jordan
```

Pointing to the part you are unsure about saves the reviewer time and gets you better feedback.

## Tone and courtesy

Be polite and direct at the same time. "Could you..." and "Would you be able to..." are polite without being vague. Avoid stacking softeners ("I was just wondering if maybe possibly..."), which hide the ask. Avoid all caps and lots of exclamation marks, which read as shouting.

When you write to someone senior or outside your team, keep it a little more formal. When you reply to a teammate in a quick thread, a shorter style is fine. If you are unsure, mirror the tone of the person you are writing to.

## Before you hit send

Run this quick checklist:

- **Subject line:** could someone find this email by searching for it in a month?
- **First two sentences:** do they state the ask and the deadline?
- **Recipients:** is the person who must act in "To"? Are people who only need to know in "Cc"? Did you remove anyone who does not need it?
- **Attachments and links:** did you actually attach the file you mention? Do the links open for someone outside your account?
- **Proofread:** read it once out loud, or at least slowly. Check names, dates, numbers and units.
- **Sensitive content:** never put passwords, patient data or other confidential information in email unless your organization's policy says how.

## Common mistakes

- **Burying the ask** at the bottom of a long story.
- **Several unrelated requests in one email.** The reader answers one and forgets the rest. Send separate emails, or number the requests.
- **No deadline.** "Soon" means different things to different people. Give a date and time.
- **Reply-all by habit.** Only reply to everyone when everyone needs the reply.
- **Writing while angry.** Save it as a draft and reread it later, or talk in person.

## Following up

If you get no reply, follow up politely after a reasonable wait (often two working days, sooner if the deadline is close). Reply in the same thread so the context is there: "Hi Priya, following up on this. Thursday's deadline still stands. Is Wednesday afternoon possible?"

## Quick recap

- Put the ask and the deadline in the subject line and the first two sentences.
- Give only the context the reader needs, in bullets.
- Be polite and direct; make the next step obvious.
- Check recipients, attachments and facts before sending.

## Try it

Open the Do tab. You will rewrite a real request of your own into a clear email using the five-part pattern.


Write a concise request email that puts the ask and the deadline first.

Emails that get answers

8 Email Etiquette Tips - How to Write Better Emails at Work

How To Write A Professional Email - 4 Professional Email Writing Tips

Underline the main point of the paragraph. Write it as your first sentence, starting with what the reader should do.

Change every passive sentence into the active voice, so it says who does what.

Replace long words with common ones (for example: utilization -> use, due to the fact that -> because, refrain from -> do not).

Replace vague words ("significant number", "near future") with specific ones. Invent realistic numbers and a date for the practice paragraph.

Split your text into sentences of about 20 words or fewer.

Now take a paragraph of your own and repeat the five steps above on it.

Read both rewrites out loud. Fix any sentence where you run out of breath or stumble.

## Why it matters

Technical work produces a lot of writing: bug reports, lab notes, test results, design notes, incident summaries, safety notices. The people who read them are usually busy, often switching between tasks, and sometimes reading in their second language. If they misread your text, the cost can be real: a wrong setting on a machine, a bug fixed in the wrong place, a sample run with the wrong method.

Plain language is not "dumbing down". It is writing that your intended reader can find, understand and act on the first time they read it. Experts prefer it too, because it saves them time.

## Know your reader first

Before you write, answer three questions:

1. **Who will read this?** A teammate who knows the system, a manager who needs a decision, a customer who has never seen your code?
2. **What do they already know?** This decides which terms you must define.
3. **What should they do after reading?** Approve something, fix something, follow a procedure, or just stay informed?

The same facts can need very different text. A teammate wants the error message and the commit hash. A manager wants the impact and the decision you need from them.

## Seven plain-language rules

1. **Put the main point first.** State the conclusion or the request, then the details.
2. **Use short sentences.** Aim for an average of 15–20 words. One idea per sentence.
3. **Use the active voice.** "The script deletes old logs" is clearer than "Old logs are deleted by the script". The active voice tells the reader who does what.
4. **Choose common words.** "Use" instead of "utilize", "start" instead of "commence", "about" instead of "approximately".
5. **Define terms and acronyms once.** "Limit of detection (LOD)" the first time, then "LOD".
6. **Be specific.** Replace "a while", "a lot" and "soon" with numbers, units and dates.
7. **Use structure.** Headings, short paragraphs, bullet lists for items and numbered lists for sequences. Readers scan before they read.

## Worked example 1: an engineering update

Before:

```text
It has been determined that, due to the fact that a significant number
of the sensor readings were found to be anomalous during the period of
the testing that was conducted last week, the utilization of the
current calibration values should be discontinued until such time as
a re-evaluation can be performed.
```

That is one sentence of 52 words, written in the passive voice, and it never says who should do what. After:

```text
Stop using the current calibration values for the line 3 pressure
sensors. In last week's test, 41 of 200 readings (about 20%) were
outside the expected range. Maria will recalibrate the sensors by
Friday. Until then, use the backup values in calibration-v6.csv.
```

Four short sentences. The reader knows what to stop, why, who is fixing it, by when, and what to do in the meantime.

## Worked example 2: a bug report

Before:

```text
The app is broken when you try to log in sometimes.
```

After:

```text
Login fails with "Error 500" for accounts with a plus sign in the
email address (for example, sam+test@example.com).

Steps to reproduce:
1. Go to /login.
2. Enter sam+test@example.com and the correct password.
3. Click "Log in".

Expected: you reach the dashboard.
Actual: a blank page with "Error 500".
Happens every time on version 2.4.1, Chrome and Firefox.
```

The second report can be fixed. The first one starts a conversation.

## Numbers, units and precision

Technical readers act on numbers, so be careful with them:

- Always give units: "4.2 mL", "250 ms", "3 kN".
- Keep the number of significant figures honest. Do not write 12.3456 V if your meter reads to 0.1 V.
- Write dates in a format nobody can misread across countries, such as 2026-03-04 or "4 March 2026".
- Say which version, batch, build or instrument you mean.

## Common mistakes

- **Writing for yourself.** Notes that make sense to you today may mean nothing to a colleague, or to you in six months.
- **Hiding the point** after a long background section.
- **Undefined jargon and acronyms**, especially team-specific ones.
- **Long, nested sentences** with "which", "that" and "due to the fact that" stacked together.
- **Vague words** like "fast", "large", "recently" and "some issues".

A quick self-test: read your text out loud. Where you run out of breath, split the sentence. Where you stumble, use a simpler word.

## Quick recap

- Decide who the reader is and what they need to do.
- Main point first, short sentences, active voice, common words.
- Define terms once; give numbers with units, versions and dates.
- Use headings and lists so the text can be scanned.

## Try it

Open the Do tab. You will take a dense paragraph and rewrite it using the plain-language rules, then check your version against them.


Use plain-language rules to make technical text easy to understand and act on.

Writing for technical readers

Plain Language For Everyone, Even Experts

Plain Language Explained

Write a title that says what the procedure achieves, plus one or two sentences on purpose and scope.

List everything needed before starting: tools, materials, accounts or access, and how long it takes.

Write the steps as a numbered list, one verb-first action per step, with exact names and values.

After each important step, add what the reader should see or notice if it worked.

Add any caution before the step it applies to, and a final "Check that it worked" step.

Add a short troubleshooting section with the two most likely problems and their fixes, plus an owner and a "last checked" date.

Give the document to someone who has never done the task. Watch them follow it without helping, and note every place they hesitate or ask a question.

Fix each problem you noted and update the "last checked" date.

## Why it matters

Much of technical work is repeated: setting up a development environment, calibrating an instrument, restarting a service, changing a filter, onboarding a new teammate. When the steps live only in one person's head, the work stops when that person is away, and mistakes creep in. A good how-to document, often called a procedure or SOP (standard operating procedure), lets someone else do the task correctly the first time.

In regulated fields such as clinical labs, manufacturing and utilities, written procedures are required, and people are trained and audited against them. In software teams, the same idea shows up as READMEs, runbooks and setup guides.

## The core idea: one action per numbered step

A procedure is a recipe. The reader follows it while doing the task, often with their hands busy and their attention split. So each step should be:

- **Numbered**, because order matters.
- **One action**, starting with a verb: "Open", "Enter", "Press", "Wait".
- **Specific**: exact names, values and units.
- **Followed by what the reader should see**, so they know it worked.

## A simple structure

Most how-to documents can use the same skeleton:

1. **Title**: what the procedure achieves. "Set up the project on a new laptop", not "Setup notes".
2. **Purpose and scope**: one or two sentences on when to use it and when not to.
3. **Before you start**: prerequisites, access, tools, materials and how long it takes.
4. **Safety or warnings**: anything that could harm a person, data or equipment, placed *before* the step it applies to.
5. **Steps**: numbered, one action each, with expected results.
6. **Check that it worked**: a final test.
7. **Troubleshooting**: the two or three most common problems and their fixes.
8. **Owner and date**: who maintains it and when it was last checked.

## Worked example

Here is a weak version of a software setup guide:

```text
Install stuff, clone the repo, set up the env file and run it. Ask
Dev if it doesn't work.
```

And a usable one:

````markdown
## Run the API on your laptop

Use this to run the API locally for development. It takes about
15 minutes. It does not cover production deploys.

### Before you start
- Node.js 22 installed (check with `node --version`).
- Read access to the GitHub repository.

### Steps
1. Clone the repository:
   ```bash
   git clone git@github.com:example/api.git
   ```
2. Move into the folder: `cd api`
3. Install the dependencies: `npm ci`
   You should see "added ... packages" with no errors.
4. Copy the example settings file: `cp .env.example .env`
5. Start the server: `npm run dev`
   You should see "Listening on port 4000".

### Check that it worked
Open http://localhost:4000/healthz in a browser. It shows `ok`.

### Troubleshooting
- "node: command not found": install Node.js 22, then repeat step 3.
- "Port 4000 is already in use": stop the other process, or set
  PORT=4001 in .env.

Owner: Platform team. Last checked: 2026-10-01.
````

Notice how the expected results ("You should see...") let the reader catch a problem at the step where it happens, instead of at the end.

The same structure works away from a computer. For example, a procedure for replacing a printer toner cartridge would list the cartridge model under "Before you start", put "Turn off the printer and let the fuser cool for 10 minutes" as an early step with the reason, and end with "Print a test page".

## Warnings: put them before the step

A warning placed after the step is read too late. Use clear labels and say what could happen:

```text
CAUTION: The next step erases every record in the test database.
Confirm you are connected to "test", not "production".
6. Run: npm run db:reset
```

For physical work (machinery, electricity, chemicals), a written procedure does not replace the training and supervision your employer or school must provide. Never write or follow a safety-critical procedure on your own without that.

## Test it on someone else

The only real test of a procedure is watching someone else follow it. Give it to a person who has never done the task. Do not help them. Note every place they hesitate, guess or ask a question. Each one is a step to fix. This is sometimes called a "hallway test" or "usability test" for documents.

## Common mistakes

- **Several actions in one step** ("Open the app, log in, go to settings and change the region").
- **Missing prerequisites**, so the reader gets stuck at step 6.
- **Vague words**: "set the temperature appropriately", "wait a bit".
- **No expected results**, so mistakes are only found at the end.
- **Out-of-date documents.** Add an owner and a "last checked" date, and update the procedure whenever the process changes.

## Quick recap

- Title, purpose, prerequisites, warnings, numbered steps, check, troubleshooting, owner.
- One verb-first action per step, with what the reader should see.
- Warnings go before the step they apply to.
- Test the document on someone who has never done the task.

## Try it

Open the Do tab. You will write a numbered procedure for a task you know well and test it on another person.


Write a numbered procedure that someone else can follow correctly the first time.

Writing a how-to document

Writing Instructions and Procedures

How to Write an SOP in 9 Minutes (Standard Operating Procedure)

Write emails, technical text and how-to documents that busy readers can understand and act on the first time.