What Short I Must Say Actually Means in Practice
I keep running into people who think being concise is the same as being vague. It is not. Short I Must Say is a communication discipline where you strip everything down to what actually carries meaning, then you leave the rest on the floor. People use it in standups, in written reports, in Slack threads, sometimes in code comments where every line matters. The technique forces you to decide what is essential before you start writing. That decision-making part is where most teams stall. You spend ten minutes trying to make a single paragraph "short" when you should have spent two minutes deciding which two sentences the reader actually needs.
How to Apply the Short I Must Say Method
Here is the actual process I use with my teams. First, write the full version without holding back. Get every detail, every caveat, every nuance onto the page. Do not edit anything at this stage. Then, take a second pass and cross out every sentence that the reader could infer from context. Not every sentence that sounds nice. Every sentence that is redundant given what the audience already knows or can easily derive. The third pass is the brutal one. Look at each remaining sentence and ask whether any word inside it can be removed without changing the meaning. Usually three to four words per sentence survive this cut. What you are left with is your Short I Must Say output. I remember one specific situation where this broke down completely. We had a postmortem document where leadership wanted everything summarized using this method. I applied it straight to a technical incident report that involved a cascading failure across three services. The shortened version became so stripped down that it read like: the database locked, the API timed out, the queue backed up. Someone who was not there lost three weeks understanding what actually happened. The fix was to keep the Short I Must Say format for the executive summary section only, and leave the detailed timeline untouched in a separate appendix. That split saved us from another meeting about why the summary was insufficient.
Common pitfall: people confuse brevity with omission of necessary context. Short I Must Say is not about removing information that the reader needs to act correctly. It is about removing information the reader already has or does not need yet. The distinction matters because the wrong kind of short leads to confusion, not clarity.
Get the Full Details
Where This Method Fails and What to Use Instead
Short I Must Say does not work well for instructional documentation where step-by-step precision matters more than speed. If you are writing a runbook for an on-call engineer at 3 AM, the method will cut away exactly the details they need. Same problem with legal or compliance writing where ambiguity is expensive. In those cases, plain language is better than compressed language. You want every condition stated explicitly even if it makes the document longer. Another honest limitation: the method assumes your audience shares enough context with you to fill in the gaps. If you are communicating across teams that do not interact regularly, the shortcut leaves holes. I have seen engineering summaries get sent to product managers who had no idea what "the queue backed up" meant in their domain. The workaround is a single glossary line or a reference to a shared doc rather than trying to bake every definition into the text itself. That keeps the document short while preserving comprehension. Short I Must Say is useful when you need to compress a message without losing accuracy. It is not useful when the message itself is the accuracy. Know which case you are in before you start cutting.
