Why emails go wrong
Most people read work email quickly, between other tasks, often on a phone. An email that buries its request in the fourth paragraph, or mixes three topics into one message, may be skimmed, half-answered or ignored. The result is delay and extra messages that cost more time than careful writing would have.
The fix is mostly structure. This article looks at how to arrange a technical email so the reader can see at once what you want and what they need to know. It is about the email format itself, rather than team communication in general or meeting practice.
Decide what you want before you write
Ask yourself what you want the reader to do. Common purposes include:
- Request an action or a decision
- Ask a question
- Inform about a result, change or problem
- Confirm something agreed elsewhere
If you cannot say it in a sentence, the email is not ready. If there are several unrelated purposes, consider sending separate emails, since each can then get its own reply and be filed or searched by its own subject.
Write a subject line that works
The subject line is read first and used later to find the message. Make it specific and include the project or item, plus the action if there is one.
| Weak | Better |
|---|---|
| Question | Question: sample rate for test rig 2 data logger |
| Update | Update: bracket test finished, results attached |
| Urgent!! | Decision needed by Friday: choose supplier for enclosure |
Labels such as “Action needed”, “FYI” or “Decision needed” help readers triage. Use urgency markers sparingly, or they stop meaning anything. If the thread’s topic changes, change the subject line too.
Lead with the request or the point
Put the main point in the first one or two lines. Then give the context needed to act on it.
Compare these openings:
- Buried: “Following the test on Tuesday and the discussion we had last week about the enclosure, I looked at the options and wanted to follow up on a few things…”
- Direct: “Could you confirm by Friday which enclosure material we should order? I recommend aluminium; the reasons are below.”
The second lets the reader understand the ask even if they stop reading. Include who should do what and by when, whenever that applies. If a deadline is firm, say why, briefly.
Give the supporting facts in a scannable form
After the opening, supply what the reader needs to respond. Short paragraphs, each on one topic, are easier to follow than a single block. When the content is genuinely a list, use one:
- numbered steps when order matters
- bullet points for parallel items such as options or findings
- a small table for comparisons across the same attributes
Keep to the facts the reader needs. Include relevant numbers with units, dates, file names and version identifiers, rather than vague references such as “the latest file” or “the earlier test”. If you refer to an earlier message or document, name it exactly. For measurements, mention how and when they were taken if that affects interpretation, and distinguish observations from your interpretation.
When you present options, state your recommendation if you have one, and the main trade-off behind it. A simple comparison can follow the approach described in decision matrices, but in an email it should stay short.
Be careful with attachments and screenshots
State in the body what each attachment is and why it is there; a reader should not need to open it to understand the message. Use descriptive file names with dates or versions. Large files are often better shared as a link to a controlled location than attached, which also avoids multiple versions floating around. Where an image matters, crop it to the relevant part and say what to look at.
If you report a defect or a failure, include the details someone would need to reproduce it, as described in how to write a good bug report. A clear problem report prevents a round of clarifying questions.
Adjust tone and length to the reader
Aim for polite and direct. Use plain wording, as in plain language, and avoid unexplained abbreviations when writing to people outside your team. Keep emails short enough to read in one sitting; if the content is long or complex, put a summary at the top and consider moving the detail to a document or a call.
Think carefully about the recipient lines:
- To: people who need to act.
- Cc: people who need to know. Do not copy people by habit.
- Reply all: use only when everyone needs the reply.
Tone is hard to judge in text. Where an issue is sensitive, such as a disagreement or criticism, consider a conversation instead, or at least read your message once more as though you were the recipient. Ideas on handling these cases appear in constructive feedback and technical disagreements.
Follow up sensibly
If you have not had a reply by the date you set, a short follow-up that restates the question works better than a general nudge. Quote or repeat the request so the reader does not need to search for the earlier message. Once an action is complete, close the loop with a brief confirmation, so others know the matter is settled.
For decisions that matter later, such as an agreed change in scope or a design choice, make sure the outcome is recorded somewhere more durable than an inbox, such as a decision log or the project notes. Email is searchable but not a reliable archive on its own.
Pre-send checklist
- Is the purpose clear from the subject line and first lines?
- Is it obvious who should do what, and by when?
- Are the key facts, numbers and units correct?
- Are attachments included, named and explained?
- Are the right people on the recipient lines?
- Would a stranger forwarded this message understand it?
Reading the message once more before sending catches most problems. Organisational rules on confidentiality, security and record keeping differ, so follow the policies of your workplace when deciding what to put in email.