4. Chat Messages That Actually Get Answered

Description

The work chat is where you open your mouth in English the most times a day without anyone seeing your face. Slack, Teams, Discord, the team channel: that's where you ask for help, flag a problem, coordinate a deploy. And that's where a lot of Spanish-speaking developers lose hours — not because of their English, but because the message they write doesn't give the other person what they need to respond. The good news is that a chat message that works doesn't depend on your fluency: it depends on a structure you can learn in one lesson and apply with a template pinned next to you while you write.

The previous lesson gave you the clear sentence: active voice, explicit subject, short sentences that read effortlessly. This lesson takes those sentences and arranges them inside a complete message. Because writing a good sentence is one thing, and putting together a request for help that someone in another time zone can answer in a single pass — without writing back "what did you try?" or "which service are you talking about?" — is a different thing entirely. The goal isn't to sound elegant. The goal is for the answer to arrive on the first try.

An honest reminder of the floor we're working from: this guide assumes you already read technical English with some ease and can hold a couple of minutes of speech with mistakes. Chat is precisely the friendliest terrain for you, because you write with time, review before sending, and nobody's rushing you. If you feel like "your English isn't enough" to ask for help in a public channel, this lesson is exactly for you: you're going to see that the message that actually works is shorter and simpler than the one you probably write today.

Connection to the module: This is the module's first living writing format. Lessons 2 and 3 gave you the asynchronous context and the clear sentence; here you put them to work in the channel where you're seen the most. What you learn to structure in a chat message — context, what you tried, the concrete question, the register of courtesy — is the same backbone that holds up an issue (lesson 5), a PR description (lesson 6), and a status update (lesson 7). Chat is the short, fast version of everything that follows. Master this, and the rest is the same skeleton with more meat on it.

Why "hi" and waiting costs you hours

Let's start with the most expensive and most common mistake, the one that has nothing to do with grammar. It's this one:

[9:02] you: hi
[9:02] you: are you there?

And then you wait. The other person sees "hi," has no idea what you want, is in the middle of something else, and decides to reply once they're done. Twenty minutes pass. They answer "hey, what's up?" Now you explain the problem. They read it, ask for a missing detail. Another ten minutes. It's one in the afternoon and you still haven't reached the real question.

There's even a site with its own name for this: "no hello." The idea is simple and it's a real cultural norm on distributed tech teams: greeting someone and waiting for them to greet you back before saying what you need wastes time for both of you. Not because greeting is rude — it's because chat is asynchronous. When you write "hi" and wait, you're forcing the other person into a real-time conversation they might not be able to have right now.

The rule that replaces "hi and wait" is direct: a brief greeting and, in that same message or the very next one, all the context and the question. Like this:

Hi Sarah — quick question about the payments service when you have a sec.
I'm getting a 401 from /charges even with a token that works on staging.
Any idea if prod uses a different auth scope?

Notice what changed. Sarah can read this between two tasks, without rushing, and answer with what she knows — or route you to whoever does — without a single question back. You gave her the greeting (yes, it's still there: "Hi Sarah"), the topic, what you already tried, and the concrete question. One single round trip. That's a message that gets an answer.

A cultural nuance, not a linguistic one: on many Latin American teams a long greeting is a sign of respect, and jumping straight to the point can feel cold. In English technical chat it's the opposite: getting to the point is a sign of respect for the other person's time. You're not being curt; you're being considerate. The "Hi [name]" at the start already carries all the courtesy the channel needs.

The anatomy of a message that gets an answer

Every good request message in chat has the same four pieces. Not always in four lines — sometimes they fit in two sentences — but all four need to be there. Think of it as a paramedic's radio report: they give the location, what they see, what they already did, and what they need, all in one go, because someone on the other end has to decide fast without asking again.

Here's the full template, to copy and fill in for the first few weeks until it comes out on its own:

Hi [name] — [context in one line].
[What you tried] I already tried X and Y, but Z still happens.
[The question] Do you know [concrete question]?
[What you need] No rush / when you get a chance / it's blocking me, so today if possible.

A real example built with the template:

Hi Miguel — I'm setting up the local database for the orders service.
I already ran the migrations and the container is up, but the app can't connect (connection refused on 5432).
Do you know if there's an extra env var I'm missing?
No rush, sometime today would be great.

Compare it to the version most people write starting out:

hey, the database isn't working, can you help?

The second one isn't "worse English" — it's actually grammatically correct. It's a worse message, because it forces Miguel to ask you which database, which service, what exact error, and what you already tried. Four round trips that the first version resolved in one. Your English level didn't make that difference. The structure did.

Calibrated courtesy: asking without sounding like an order

Here's the specific problem the market research flagged across several ecosystems, and one almost no general English course teaches you. In Spanish we make requests with the imperative all the time, and it sounds perfectly friendly: "Pásame el link," "Revisa el PR," "Corre los tests otra vez." The friendly tone lives in the voice, the context, the relationship. But when you translate that imperative word for word into written English —

Send me the link.
Review the PR.
Run the tests again.

— it sounds like an order. Curt, blunt, a boss talking to a subordinate. Not because English is more formal, but because in written English a bare, unwrapped imperative reads as a non-negotiable instruction. And you don't want to give a coworker instructions; you want to ask them a favor.

The solution isn't to become ceremonious. It's to learn a handful of calibrated courtesy formulas that turn an order into a request. There are only a few and they repeat a lot:

Those five cover almost everything. Look at the transformation:

❌ Send me the link.
✅ Could you send me the link when you get a chance?

❌ Review the PR.
✅ Would you mind taking a look at the PR when you have a moment?

❌ Fix the failing test.
✅ Any chance you could look into the failing test? It's blocking the deploy.

None of the ✅ versions is notably longer, and none is servile. They're simply requests instead of orders.

There's a trap on the opposite end worth avoiding too: overdoing the courtesy. Words like "kindly" ("Kindly send me the link") or piling on "please" in every sentence sound stiff and, oddly, give away a non-native speaker more than bluntness does. The correct register for technical chat is friendly and direct, not formal. A "Could you…?" with the person's name at the start is all you need.

The mental rule that solves 90% of cases: be direct about the facts, indirect about the requests. You can and should be direct describing the system — "The build is failing on main" is perfect, it's a fact, not an accusation. But when you're asking a person for something, wrap it: "Could you take a look?" Fact: direct. Person: with a formula.

Asking for help without sounding dependent

There's a legitimate fear behind a lot of poorly written messages: looking like you don't know how to do your job. That fear pushes people to two extremes, and both fail. One extreme is never asking and staying stuck for hours out of pride. The other is asking so fast and so raw that you look incapable of solving anything on your own.

The middle ground has a concrete shape, and it's the same one senior developers use when they ask for help: show your work before you ask. A good request for help demonstrates, in one or two lines, that you already tried. That completely changes how the other person reads you: you're not someone dumping their problem, you're someone who got stuck after putting in reasonable effort.

The pattern is called, in English, showing your "what I've tried." Compare:

❌ I can't get the tests to pass. What do I do?

✅ The auth tests are failing with a 500. I already checked the DB connection
   and reset the test data, but it still fails only in CI, not locally.
   I suspect it's an env var that's missing in the pipeline — does that sound right?

The second version does three things the first doesn't: it says precisely what's failing, it says what got ruled out, and — this is the powerful part — it offers a hypothesis ("I suspect it's an env var… does that sound right?"). Proposing a theory, even a wrong one, positions you as someone who thinks, not as someone waiting to be handed the answer. And it gives whoever's helping you a starting point instead of a blank canvas.

Phrases in English that help frame a request for help without sounding dependent:

• I've been looking into X and I'm stuck on… — He estado investigando X y me trabé en… (shows prior effort).
• I suspect the issue is Y, but I'm not sure — does that make sense? — Sospecho que el problema es Y, pero no estoy seguro. (hypothesis + humility).
• Am I missing something obvious here? — ¿Se me está escapando algo obvio? (lowers your guard, invites correction with no drama).
• What's the right way to do X in this codebase? — ¿Cuál es la forma correcta de hacer X en este código? (asks about the team's convention, not the basics).

Look at the last one. Asking "What's the right way to do X in this codebase?" doesn't reveal ignorance; it reveals that you understand every team has its own conventions and that you'd rather follow theirs than invent your own. That's senior judgment, not weakness.

Declaring a blocker early

There's a type of message a lot of developers delay out of embarrassment, and delayed, it becomes the most expensive one of all: flagging that you're blocked. A blocker is anything stopping you from moving forward that you can't resolve on your own: a permission you don't have, a decision that depends on someone else, a service that's down, an answer you're waiting on.

The instinct is usually to stay quiet and "keep trying" so you don't have to admit you couldn't do it. That's the wrong instinct. On a team, a silent blocker costs the project far more than an announced one. If you flag it at 9 in the morning, someone can unblock you by 9:30 and you lose half an hour. If you sit on it until the next day's standup, you lost a whole day. Flagging early isn't weakness: it's exactly what's expected of a responsible professional.

There are two expressions in English that open these messages and that you should recognize and use:

• Heads up: — Aviso / para que lo sepan. Used at the start of a message to flag something people need to know, with no drama. Heads up: the staging API is down, so anyone testing against it will see errors.
• Flagging early: — Lo señalo con tiempo. Literally "raising the flag early." It communicates that you're warning on purpose before it becomes urgent. Flagging early: I'm blocked on the design review and can't start the frontend until it's approved.

A good blocker message has three parts, and all three matter:

A full example, the kind that makes you look good, not bad:

Heads up — I'm blocked on the payment provider API keys.
I can't test the checkout flow without them, so that task is on hold.
Could you grant access or tell me who owns it? A 5-min call also works if that's faster.

That message says, without one word too many: I know exactly what's stopping me, I understand the project impact, and I've already thought about how to fix it. Nobody reading that thinks "doesn't know how to work." They think "flagged it on time and with a solution." That's the difference between a blocker that makes you look junior and one that makes you look reliable.

Happy to hop on a quick call is a golden phrase for technical chat. Offering it shows willingness without demanding the meeting, and often the offer alone makes the other person answer in writing to avoid the call. Either way, you win.

Threads, mentions, and code formatting

The message can be perfect and still get lost if you don't use chat's three mechanical tools correctly. None of them are about language; all of them affect whether you get a reply.

Threads. A thread is a nested conversation hanging off a message, so it doesn't flood the main channel. The rule: if you're replying to or following up on something, do it in that message's thread, not as a new loose message. It keeps the context together and leaves the channel readable for everyone else. When something in the thread matters to the whole team, there's an option to "also send to channel" to surface it once. Useful phrase: Let's move this to a thread to keep it together.

Mentions. Writing @name sends that person a notification. It's your tool for grabbing the attention of whoever needs to act — and precisely for that reason, it's used with aim:

Overusing @channel is the fastest way to get people to mute your channel. Mention the person who can solve it, not the crowd.

Code formatting. This instantly separates a professional message from an amateur one, and it costs nothing:

• Wrap variable names, commands, files, or short values in backticks: writing `user_id` or `npm install` displays them as user_id and npm install, readable and without the chat "autocorrecting" your text.
• For multiple lines of code or a stack trace, use a triple-backtick block. Never paste an error as run-on text in the middle of a sentence, and never send a screenshot of text that could have been copied: whoever's helping you can't select, search, or copy from an image.

Compare:

❌ getting an error TypeError cannot read property id of undefined in user.js line 40

✅ Getting this in `user.js`:

TypeError: Cannot read property 'id' of undefined at getUser (user.js:40)

Looks like `user` is undefined before line 40 — does that ring a bell?

The second version reads at a glance, the error can be copied, and it already comes with a hypothesis. It's the same content, formatted the way someone who knows what they're doing formats it.

What to expect and how to practice it between lessons

Let's be clear about the curve, because this module gets practiced by writing, not reading. The first several times you're going to take longer to write a chat message than before, and that's correct: you're moving from "I write whatever comes out first" to "I assemble the four pieces." That conscious effort is temporary. Here's what's going to happen:

• Weeks 1-2: You write your messages with the template next to you and it takes a bit longer. Every message comes out more complete, but you still have to think it through. You notice you get answered on the first try more often.
• Weeks 3-4: The four pieces start coming out without looking at the template. The courtesy formulas (could you, when you get a chance) are already automatic. You format code without thinking about it.
• After that: You write a complete, polite, actionable request in the time it used to take you to write "hey, quick question." And the number of messages that go unanswered drops sharply.

To get there, here's a concrete practice cadence for this module's weeks. It's not theory: it's what you do between one lesson and the next.

• Daily, with your real messages (0 extra minutes): Every time you're about to ask for something over chat at work or in any technical community in English, before sending, check that the four pieces are there: context, what you tried, the question, what you need. At first, pin the template in a note and keep it visible. You're practicing with real material and no extra work.
• Weekly cadence (15 minutes): Save two chat messages you sent in English this week into your log. Rewrite them applying this lesson: did the imperative turn into a request? Was "what I tried" missing? Was the blocker flagged early enough? Comparing your raw version to your edited version is where the real learning happens.
• Phrase banks: Build your own short list of formulas that already come out naturally for you — your "Could you… when you get a chance?", your "Heads up, I'm blocked on…", your "Does that sound right?" Five or six phrases of your own, lifted from real messages on your team, are worth more than a hundred from a generic list. Copy how the good communicators on your channel write; your company's English has its own dialect, and it's worth speaking it.

One gate worth marking before moving on: this module is about writing, and writing gives you the luxury of reviewing before sending. Take full advantage of that now, because the structures you internalize while writing — giving context first, asking instead of ordering, flagging early — are the same ones you're going to need to say out loud, with no draft, in a standup later on. Writing well today is rehearsing speaking well tomorrow. But that's further ahead, with its own method; for now, your advantage is time, and chat is where you cash it in.

And one last thing, for anyone who arrived at this lesson thinking their English isn't enough to ask for help in a channel full of people who "know more." Look at what you just learned to do: structure a request, calibrate courtesy, show your work, flag a blocker with a solution attached, format an error so it's readable. None of that was conversational fluency. It was structure, and structure is learnable. The developer who writes "hey, the database isn't working" in perfect English gets a worse response than you do with your "Hi Miguel — I already ran the migrations, but the app can't connect… any idea what env var I'm missing?" even if you slip up on an article somewhere. In technical chat, the person who speaks the best English doesn't win. The person who communicates the best wins. And that, starting today, is you.

Exercises

Practice with cases similar to what you'll see on a real team. Try writing your own English version before opening the solution.

Exercise 1 — From "hi and wait" to a complete message

You need to ask your coworker Laura why the CI pipeline is failing at the lint step. You've already run the pipeline twice and confirmed the linter version matches what you have locally. Write the complete message in English, applying the four-piece template (context, what you tried, the question, what you need) with no "hi and wait."

Hi Laura — quick question about the CI pipeline.
I already reran the lint step twice and confirmed the linter version matches what I have locally, but it still fails only in CI.
Any idea what could cause that?
No rush — whenever you have a minute.

Exercise 2 — Calibrate the courtesy

Rewrite these three imperatives as requests, using a different formula from the calibrated courtesy table each time (don't repeat the same one twice):

1. Send me the staging credentials.
2. Approve my PR.
3. Restart the server.

Exercise 3 — Declare a blocker with its three parts

You're blocked: you need read access to the staging database to reproduce a bug, but you don't have permission and don't know who administers it. Write the complete blocker message (the blocker, the impact, what you need), opening with Flagging early:.

Flagging early: I don't have read access to the staging database.
I can't reproduce the bug reported in ticket #482 without it.
Could someone grant me access, or point me to who owns it? Happy to hop on a quick call if that's faster.

Exercise 4 — Show your work and format the error

You have this poorly written message, all on one line, with no prior attempt or formatting:

getting an error Cannot find module 'express' when I run npm start, no idea why

Rewrite it adding: (a) what you already tried — for example, checking that the module is in package.json and rerunning npm install — (b) a hypothesis, and (c) the error in a code block.

Getting this when I run `npm start`:
```
Error: Cannot find module 'express'
```
I already checked that `express` is listed in `package.json` and reran `npm install`, but it still fails.
I suspect `node_modules` didn't get generated correctly — does that sound right?

Summary and next step

Review this lesson's thread: you replaced "hi and wait" with the four pieces in a single message — context, what you tried, the concrete question, and what you need. You learned to wrap a request in a calibrated courtesy formula instead of a bare imperative, to show your work with a hypothesis before asking for help, to announce a blocker early with its three parts, and to not lose any of that to poor use of threads, mentions, or code formatting.

Before moving on, you should be able to:

• Open a request message with the four pieces — context, what you tried, the question, what you need — with no "hi and wait."
• Turn an imperative into a polite request using at least two different formulas from the table (Could you…?, Would you mind…?, Any chance you could…?).
• Ask for help by showing what you already tried and a hypothesis, instead of describing the problem raw.
• Announce a blocker early with its three parts — the blocker, the impact, the proposal — using Heads up: or Flagging early:.
• Use threads, mentions (@person versus @here and @channel), and code formatting without anyone having to correct you.

In the next lesson we move up from chat's ephemeral conversation to the permanent record: issues, bug reports, and commit messages. It's the same skeleton you built here — context, precision, a clear request — but now written to last, so someone reading it six months from now understands what happened without being able to ask you. The "what I tried" you practiced in chat becomes, there, the steps to reproduce a bug. It all connects.

Resources

• Please Don't Say Just Hello In Chat — the reference site on the "no hello" anti-pattern: why greeting and waiting wastes time on both sides of an asynchronous chat.
• Use threads to organize discussions — Slack's official guide on when and how to use threads so you don't flood the main channel with follow-ups.
• Format your messages in Slack — Slack's official documentation on backticks, code blocks, and the rest of the formatting that separates a professional message from an amateur one.
• GitLab Communication (The GitLab Handbook) — how a 100% remote company documents its asynchronous communication norms; the same "context first" spirit applied at the scale of an entire organization.