You're stuck. You open Slack or Teams and message the colleague who knows the area. You want them to really get it, so you tell them everything: yesterday's handoff, the PO asking for an update, the ticket comments going back to Monday, the payments channel, the risk team that was stuck in a war room. Twenty lines later, at the very bottom, you write: "can you take a look when you get a chance?" Your colleague sends a thumbs-up, and that's the last anyone hears of the thread.
The habit here is a small one. The first line of your message is a question your colleague can answer this week, and ideally today. After it come three supporting lines at most. Everything else waits until they ask for it. This is for the written, async request, the one your colleague reads between two other tasks.
Why twenty lines with no question stall the thread
When a message lands in the middle of someone's day, they scan it. They don't really read it. Nielsen Norman Group has described this for web pages since 1997: people rarely read word by word, and an idea that doesn't catch them in the first few words tends to get skipped. Their study of the F-shaped reading pattern adds an awkward detail. Faced with a wall of text, a reader who wants to be efficient looks at the first lines more than the later ones, and the skipped parts can matter as much as the parts they read. Worse, the reader has no idea they skipped anything.
Style guides land on the same rule. The Microsoft Style Guide says "Lead with what's most important." Google's technical writing course asks that the start of a document answer the reader's essential questions, because a busy reader may only get through the first paragraph.
There are two caveats. This research is about reading on the web, not chat, and nobody has measured the line where a Slack thread dies. "Twenty lines" is also just an image, not a cutoff. A twenty-line message that opens with the question works fine, and a six-line message that ends in "can you take a look?" doesn't. What stalls the thread is a question that isn't on the first screen, which is exactly where a hurried reader stops. Without it, your colleague has to work out the task from your backstory or put it off. In a chat thread, "later" usually turns into Friday.
Line one: a question someone can decide
Flip the order so the essential part comes first. Journalism calls this the inverted pyramid: the essential facts go in the lead and the rest follows in order of importance, so the core survives even if the end gets cut. In military email the same idea is called BLUF, bottom line up front, which Kabir Sehgal described in HBR in 2016. It's a short opening statement that "declares the purpose of the email and action required," followed by the background as bullets. It works the same way in Slack. Your reader doesn't necessarily want the history that got you here. They want to know what it means for them.
For help requests specifically, Stack Overflow's page on how to ask a good question has the most direct instruction: "Pretend you're talking to a busy colleague and have to sum up your entire question in one sentence." In your case you don't even have to pretend. The busy colleague is real and sitting on the other end of the thread.
Two more points round this out. We tend to hint instead of asking, and people are much more likely to help when we ask outright and tell them how to help, as Vanessa Bohns explains in an interview with Cornell ILR. The more specific the ask, the better. "The more specific your request, the more effective it will be," Wayne Baker sums up in Greater Good, and he adds that a specific deadline beats a general one.
Our rule is that the first line has to be a decidable question. Your colleague can answer it with yes or no, A or B, a name, or a time. "Can you take a look when you get a chance?" isn't decidable, because it asks for attention, not a choice. Compare:
> "Can you take a look at checkout?"
> "Can you take over the checkout handoff review by 3 p.m. today, or should I ask Ana?"
With the first one, your colleague still has to figure out what to look at and what to decide. With the second, they can answer in three words.
The four-line mold
The mold is ours, but the order comes from the sources above. It has four fields, one per line:
| Line | What goes in | What stays out |
|---|---|---|
| Question | One sentence your colleague can answer: yes/no, A or B, a name, a time | "Can you take a look?", "anyone know?" |
| Already tried | What you read or tested, and where you got stuck | The ship's log since Monday |
| Decision | The choice that needs to be made, with names | "See what we can do" |
| By when | A time or a day | "Whenever", "no rush" |
"Already tried" is there because Stack Overflow asks you to record the research you've done, even when it didn't help, so nobody walks down the same dead end again. "By when" follows the MIT EECS Communication Lab, which asks you to state the action you want along with a deadline.
Here's an example. First, the wall:
> Hi, so yesterday the checkout item handoff got left halfway, the PO asked for an update, the ticket has comments since Monday, I looked at the old doc, the #payments channel, the sprint spreadsheet, I talked to the risk team but they were in a war room, the review for the other item slipped, the customer asked in the 9 a.m. email, there's a screenshot on the ticket, the log is huge, the diff touched a bunch of places, I'm not sure if the problem is the timing or the retry rule, anyway someone needs to look at this or tomorrow's deploy is at risk, can you take a look when you get a chance? thanks
There's a lot in there and no decision anywhere. The only question shows up at the end, and it doesn't ask for any choice. Here's the rewrite:
> Question: can you take over the checkout handoff review by 3 p.m. today, or should I ask Ana? > > Already tried: read Monday's ticket comments and the handoff doc; couldn't pin down the retry rule. > > Decision: I need an owner for the review now, you or Ana, so the PO isn't left without an update. > > By when: a one-line answer by 11 a.m.; the review itself by 3 p.m.
The useful content is the same. The difference is that the question is now the first thing your colleague reads.
What stays out of the first message
The wall usually grows out of good intentions. You don't want to waste your colleague's time, so you send everything at once. Then the log arrives before the question, and your colleague spends their time reading the log.
Leave these out of the first message:
- the full log and the whole diff;
- the ticket's history, told in order;
- opinions about the stack, the process, or the customer;
- any sentence that starts with "ever since March…".
None of this disappears. It becomes an offer: "I can send the relevant slice of the log if that helps."
If you have two requests, send two messages. A wall with two questions hidden in it is just a bigger wall.
This week's check: the first reply
The next step fits in a single task:
- Pick a request that's genuinely stuck, whether you already sent it or it's still a draft.
- Rewrite it in the four-line mold, with the question on line 1.
- Send it.
- Read only your colleague's first reply.
It passes if that first reply already answers the question: "yes," "ask Ana," "I'll have it by 4." It fails if the first reply is "I don't follow," "send me the context," "what do you need?", or a thumbs-up with no decision attached.
If it fails, rewrite it once, with a more decidable question on line 1. Don't send a second complaint or a second saga. If your colleague asked what you need, more context won't fix it. What was missing was the question.
A twenty-line dump without a decidable first line is a draft until it has a four-line version. If your message already opens with a question your colleague can answer in one line, it can be long and still work, and you don't need to force it into the mold.
If the message is actually feedback for a teammate, SBI feedback: the "great job, but…" the teammate cannot replay covers that. If it's your 60 seconds at standup, see standup: the AI diff you cannot narrate in 60 seconds.
This week, one rewritten message is enough. If the first reply comes back with the decision, you've saved yourself the whole thread.