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

Professional Communication & Teamwork

Finish this sentence in one breath: "When I finish, I want my audience to know ___ and to ___."

Write a 30-second opening that states the headline and, if you have one, your ask.

Choose two or three supporting points and write a few keywords for each (not a full script).

Make one visual: a single chart, diagram or photo, with a title that states the finding and labels with units.

Write a 30-second close that repeats the headline and states the ask or the next step.

Rehearse out loud with a timer. Cut material until you finish in 3 minutes or less.

Record yourself (phone or video-call recording) or present to a friend. Note one thing to improve.

Deliver it once more after making that improvement.

## Why it matters

Technical people present more often than they expect. Stand-ups, sprint demos, lab meetings, design reviews, safety briefings and client calls are all short presentations. Most of them last a few minutes, not an hour. Doing them well gets your work noticed, gets decisions made and builds trust. Doing them badly wastes everyone's time, even when the work behind them is excellent.

You do not need to be a natural performer. A short technical update is a skill with a clear structure, and it improves quickly with practice.

## The core idea: one message, three parts

Before you open any slide software, finish this sentence: "When I finish, I want my audience to know ______ and to ______." If you cannot finish it in one breath, your talk is not ready yet.

Then build a three-part talk around that message:

1. **Start with the point (about 30 seconds).** What is this update about, and what is the headline? "The new sensor firmware cut false alarms by 60%, and I'd like approval to roll it out to all lines."
2. **Give the evidence (about 2 minutes).** Two or three supporting points, no more. What you did, what you found and what it means. One visual that shows the key result.
3. **Close with the ask or next step (about 30 seconds).** Repeat the headline and say what you need: a decision, feedback, help or nothing ("no action needed, just keeping you informed").

This structure is sometimes summarized as "tell them what you'll tell them, tell them, tell them what you told them". In a short update, the repetition helps people who drifted off for a moment.

## Worked example: a 3-minute update

Here is a script outline for a junior data analyst presenting at a weekly team meeting.

```text
OPENING (30 s)
"I looked into why support tickets rose in September. Short answer:
most of the increase came from one confusing screen in the new
billing page. I'd like us to prioritise a fix."

EVIDENCE (2 min)
1. Tickets went from about 420 in August to 610 in September (+45%).
2. 150 of the 190 extra tickets mention "invoice" or "billing date".
3. They started the day the new billing page shipped (Sept 3).
   [ONE VISUAL: weekly ticket count, with the release date marked]

CLOSE (30 s)
"So roughly 80% of the increase traces to the billing page. The ask:
can design and front-end look at that screen this sprint? I'll share
the ticket list after this meeting."
```

Notice that the numbers are rounded and easy to hear. Listeners cannot reread a sentence, so "about 420" works better than "421.7 on average".

## One good visual

For a short update, one clear visual usually beats ten slides. Make it easy to read from the back of the room or on a small video-call window:

- **One idea per visual.** A single chart, diagram or photo.
- **A title that states the finding**, not the topic. "False alarms fell 60% after the firmware update" is better than "False alarm data".
- **Large text** (if people have to squint, it is too small) and only a few words.
- **Label axes and units.** Highlight the one bar or line that matters, and grey out the rest.
- **No dense tables or code walls.** If people need the detail, share it afterwards.

## Delivery basics

- **Practise out loud at least twice**, timing yourself. Most people run long the first time.
- **Speak a little slower than feels natural**, and pause after key numbers.
- **Look at people** (or at the camera on a video call), not at your slides.
- **Have notes, not a script.** A few keywords per section are enough. Reading word for word sounds flat.
- **Handle questions calmly.** Repeat or rephrase the question so everyone hears it. If you do not know the answer, say so: "I don't know yet. I'll check and send it to you today." That builds more trust than guessing.

Nerves are normal. Preparation is the best cure: knowing your first 30 seconds by heart gets you past the hardest part.

## Common mistakes

- **Starting with background** instead of the point, so people are lost before the headline.
- **Too many slides and too many numbers** for the time available.
- **Reading the slides** aloud with your back to the audience.
- **Jargon your audience does not share.** A design review with managers needs different words than one with engineers.
- **No clear ask**, so the meeting moves on and nothing happens.
- **Going over time.** Running short is never a problem; running long always is.

## Quick recap

- Decide your one message and your ask before you build anything.
- Point first (30 s), evidence (2 min), close with the ask (30 s).
- One visual with a title that states the finding.
- Practise out loud, time it, and answer questions honestly.

## Try it

Open the Do tab. You will plan, rehearse and record a 3-minute update with one visual.


Plan and deliver a clear 3-minute technical update built around one message and one visual.

Short technical presentations

How to Structure a Technical Presentation

What’s the best way to give a presentation?

Write the meeting's purpose in one sentence. If it is only a status update, ask yourself whether a written update would do instead.

Write an agenda with 2-4 topics, each with an owner, a time box in minutes and the outcome you want. Keep the total to 30 minutes or less.

Pick a note-taker and a template with three sections: Decisions, Action items, Parking lot.

Send the agenda to the participants in advance (or, for the practice scenario, write the message you would send).

Hold the meeting (or role-play it). Keep to the time boxes and put off-topic points in the parking lot.

Record every action item with one owner, a specific task and a due date.

Send the notes the same day, and put the action items where they will be tracked (a task board, shared doc or calendar).

## Why it matters

Meetings are where many technical decisions get made, and where many hours get lost. A well-run 25-minute meeting can unblock a whole team for a week. A badly run one ends with everyone unsure what was decided and who is doing what next.

You do not have to be a manager to make meetings better. Anyone can send a clear agenda, take good notes, or ask "Who owns that, and by when?" Those habits make you look organized and reliable early in your career.

## The core idea: purpose, agenda, actions

Every meeting needs three things:

1. **A purpose** you can state in one sentence. "Decide which database to use for the inventory app." If you cannot state the purpose, you may not need a meeting at all. An email or a shared document might do.
2. **An agenda** sent in advance, so people can prepare.
3. **Action items** at the end: who will do what, by when.

## Before the meeting

- **Check whether a meeting is needed.** Status updates often work better in writing. Meetings are best for decisions, problem solving and discussions that need back-and-forth.
- **Invite only the people who are needed.** Others can read the notes.
- **Keep it short.** Many meetings fit in 25 or 50 minutes, which leaves people time to get to the next one.
- **Send the agenda at least a day ahead** if you can, with any document people should read first.

A good agenda lists topics, an owner for each, a time box and the outcome you want:

```text
Inventory app: database choice
Wed 10:00-10:25, Room 2 / video link
Purpose: decide between PostgreSQL and MongoDB for the inventory app.
Pre-read: comparison doc (link), 5 minutes.

1. (5 min)  Requirements recap: Aisha
2. (10 min) Pros and cons of each option: Ben, Chloe
3. (5 min)  Decision and reasons: everyone
4. (5 min)  Action items and next steps: Aisha

Note-taker: Dev
```

## During the meeting

- **Start on time** and restate the purpose in one sentence.
- **Keep to the time boxes.** A facilitator (often the organizer) gently moves the group on: "We're at time on this one. Can we decide, or should we take it offline?"
- **Use a "parking lot".** Write off-topic but useful points in a separate list so they are not lost and do not derail the agenda.
- **Give everyone a chance to speak.** Ask quieter people directly: "Chloe, anything to add from the testing side?"
- **Capture decisions and actions as they happen**, not from memory afterwards.

## Taking notes that work

Notes are not a transcript. They record what someone who missed the meeting needs to know. A simple template:

```text
Meeting: Inventory app database choice (2026-10-14)
Attendees: Aisha, Ben, Chloe, Dev (notes)

Decisions
- Use PostgreSQL. Reasons: data is relational (items, suppliers,
  orders); the team already knows SQL; managed hosting is available.

Action items
- [ ] Ben: set up the PostgreSQL dev database. Due Fri 10-17.
- [ ] Chloe: draft the table design for items and suppliers. Due Tue 10-21.
- [ ] Aisha: tell the client the decision. Due Wed 10-15.

Parking lot
- Reporting tool choice (to discuss next week).
```

A good action item has three parts: **one owner** (a person, not "the team"), **a specific task** and **a due date**. "Look into hosting" is not an action item. "Ben: compare two hosting options and post a summary in the channel by Friday" is.

## After the meeting

- **Send the notes the same day**, to attendees and anyone else affected.
- **Put action items where work is tracked**, such as the team's task board or ticket system, so they do not live only in an email.
- **Follow up on actions** at the start of the next meeting: "Ben, how did the database setup go?"

## Joining meetings well

When you are an attendee rather than the organizer:

- Read the agenda and pre-reads, and come with your questions.
- Join on time, with your microphone muted on video calls when you are not talking.
- Keep your comments short and on topic.
- If you take on an action, repeat it back: "So I'll send the test results by Thursday."
- If you are not needed, it is fine to ask politely whether you can skip and read the notes instead.

## Common mistakes

- **No agenda**, so the loudest topic takes all the time.
- **No decision recorded**, so the same discussion happens again next week.
- **Actions without owners or dates.**
- **Too many people**, so nobody feels responsible.
- **Notes sent days later**, after everyone has forgotten.

## Quick recap

- State the purpose; send an agenda with owners and time boxes.
- During the meeting, keep time, park side topics and include everyone.
- Record decisions and action items (owner, task, date) as they happen.
- Send notes the same day and follow up on actions.

## Try it

Open the Do tab. You will prepare an agenda for a short meeting and capture its action items.


Prepare a focused agenda and capture decisions and action items with owners and dates.

Running and joining meetings

Run Meetings that Don't Suck (10 Tips)!

A Simple Way to Track Action Items in a Meeting

Think of something a classmate, colleague, friend or family member did recently that helped you. Write it as Situation, Behaviour, Impact.

Give that positive feedback to the person, in person or in a short message.

Think of a small, low-stakes behaviour you would like someone to change (for example, sending files at the last minute). Write it as SBI, describing only what a camera would record.

Add an open question to follow the constructive SBI, such as "Can you tell me how you saw it?"

Check your constructive SBI for labels ("lazy", "careless") and guesses about intent. Remove any you find.

Ask someone for feedback on something you did (a presentation, a document, a piece of code). Ask a specific question, such as "What is one thing I could make clearer?"

When they answer, listen to the end, say thank you and ask one clarifying question. Do not defend yourself.

## Why it matters

Feedback is how people and teams improve. Code reviews, design critiques, lab audits, performance check-ins and quick "can I tell you something?" chats are all feedback. Early in your career you will receive far more feedback than you give, and how you handle it shapes how fast you grow. You will also need to give feedback to peers, and doing it clearly and kindly is a skill most people never learn properly.

## Why feedback goes wrong

Most bad feedback falls into one of two traps:

- **Too vague.** "Great job!" or "That presentation was a bit off." The person does not know what to repeat or what to change.
- **Aimed at the person, not the behaviour.** "You're careless" or "You're not a team player." This feels like an attack, and people defend themselves instead of listening.

## The core idea: Situation, Behaviour, Impact

The Situation-Behaviour-Impact (SBI) model, developed by the Center for Creative Leadership, avoids both traps. You describe three things:

1. **Situation**: when and where it happened. Be specific. "In Tuesday's client call..."
2. **Behaviour**: what the person actually did or said, as a camera would record it. No guesses about their motives or character. "...you explained the outage timeline step by step and showed the graph..."
3. **Impact**: the effect it had on you, the team, the work or the customer. "...and the client said it was the first time they understood what went wrong."

Because the behaviour is observable, the other person can accept it as fact. Because the impact is about effects, not judgement, it explains *why* it matters.

After SBI, you can open a conversation: ask a question or suggest a next step.

## Worked example 1: positive feedback

Vague: "Nice work on the docs."

SBI:

```text
Situation: When I set up the project on my new laptop yesterday,
Behaviour: I followed your setup guide, and every step had the
           command plus what I should see after it.
Impact:    I was running in 20 minutes instead of the half day it
           usually takes, and I didn't have to interrupt anyone.
```

Specific praise tells people what to keep doing. It is worth giving often.

## Worked example 2: constructive feedback

Judgemental: "You always ignore the review process."

SBI, followed by a question:

```text
Situation: On Thursday afternoon,
Behaviour: the pricing change was merged to main without a review,
           and the tests were failing on that commit.
Impact:    Checkout was broken for about 40 minutes, and two of us
           stopped our own work to roll it back.
Then:      Can you walk me through what happened? I'd like us to
           find a way to make sure it doesn't happen again.
```

The question matters. You may not know the whole story. Maybe a manager asked for an urgent fix, or the review tool was down. Listening first keeps the conversation about solving the problem.

## Giving feedback well

- **Ask first** when it is not routine: "Do you have five minutes for some feedback on the demo?"
- **Be timely.** Feedback a day later is useful; feedback three months later at a review is not.
- **Be private for constructive feedback**, and public, if the person is comfortable with it, for praise.
- **Focus on one or two points.** A list of twelve problems overwhelms anyone.
- **Use "I" statements for impact**: "I was confused by..." rather than "Everyone was confused by...".
- **Check understanding**: "Does that match how you saw it?"

In written reviews, such as code or document reviews, the same rules apply. Comment on the work, not the person ("This function is hard to follow because..." rather than "You wrote this badly"), explain why, and separate must-fix points from suggestions.

## Receiving feedback well

Receiving feedback is harder than giving it, because it can sting. A simple approach:

1. **Listen to the end** without interrupting or defending yourself.
2. **Say thank you.** The person took a social risk to tell you.
3. **Ask clarifying questions** to get specifics: "Can you give me an example?" or "What would good look like?"
4. **Take time to think** before you decide what to do. You do not have to agree on the spot.
5. **Act and follow up.** "I tried what you suggested in today's demo. Did it work better?"

Not every piece of feedback is correct. You can weigh it, look for patterns across several people, and decide. But you can only do that if you heard it properly first.

## Common mistakes

- **The "feedback sandwich"** (praise, criticism, praise) used every time. People learn to ignore the praise and wait for the "but".
- **Labels instead of behaviour**: "lazy", "rude", "brilliant".
- **Guessing intent**: "You obviously didn't care about the deadline."
- **Getting defensive** when receiving, or arguing every point.
- **Only giving negative feedback.** Most teams need far more specific praise than they get.

## Quick recap

- Use SBI: the situation, the observable behaviour, and its impact.
- Follow constructive SBI with a question and listen.
- Give feedback soon, privately when it is critical, and on one or two points.
- Receive feedback by listening, thanking, clarifying, then deciding.

## Try it

Open the Do tab. You will write and practise SBI feedback, then ask someone for feedback yourself.


Use the Situation-Behaviour-Impact structure to give specific feedback and receive it well.

Giving and receiving feedback

Simple framework for effective manager feedback: The SBI model | Google People Management Essentials

Give Feedback with Situation-Behavior-Impact (SBI)

Give short technical updates, run and join meetings that end in clear actions, and give and receive feedback.