Bottom Line Up Front
Placing the conclusion and the requested action in the first lines, on the assumption that most readers will not reach the end.
Written technical communication fails predictably by building to its conclusion, because that is how the work was done. Readers do not read that way — they read the first paragraph, decide whether to continue, and act on what they have.
The discipline is to invert it: conclusion, then action requested, then reasoning, then detail. Someone who reads only the first three lines should still know what you want and why.
The habits that support it:
Say what you want. A message that describes a situation without stating the requested action produces no action, and the author concludes that nobody read it.
One topic per message. A second topic buried in paragraph four will be missed reliably.
Short paragraphs, specific subject lines, and formatting that supports scanning — because scanning is what will happen regardless of preference.
Numbers over adjectives. "Latency rose from 200 ms to 1.4 seconds" carries more than "performance has degraded significantly", and it cannot be discounted as opinion.
The asynchronous-writing point that matters for architecture specifically: a decision explained in writing scales to people who were not in the room and to the future, which is why written communication has disproportionate leverage in this role compared with meetings.