Split View: 영어로 진행 상황 보고와 나쁜 소식 전하기: 결론부터, 원인, 그다음 요청

Reporting Status and Delivering Bad News in English: Conclusion First, Then Cause, Then the Ask

Introduction: the problem is the order, not the content

Think of a situation where you have to say in English that the schedule has slipped. Most people write it like this.

Explain the background, say what took longer than expected, add how hard the team worked, and in the final paragraph say that Friday is therefore going to be difficult.

The grammar is perfect. But the person receiving this email is already irritated somewhere around the third line. Because they are reading an explanation without knowing the conclusion.

What matters here is not simply a question of manners. Push the conclusion to the back and every explanation in front of it reads as an excuse. From the reader's side, they still do not know what happened and they are being given reasons first, so they have no choice but to interpret those reasons as "I am being softened up right now." The same account of the cause becomes information when it comes after the conclusion and an excuse when it comes before.

Saying the conclusion first is the device that makes your explanation get read fairly. That is the core of this article.

Conclusion, then cause, then the ask

The standard structure for bad news is three pieces.

Part 1, the conclusion. What happened, or what is not going to work, in one sentence. No adjectives.

Part 2, the cause. Why it turned out that way, as facts. Here you talk about events, not people.

Part 3, the ask. What you need, or what the other person has to decide. With options where there are any.

If there is room, attach Part 4, prevention. In an urgent situation this can wait.

We're going to miss Friday.                          ← Part 1: conclusion

The migration turned up about forty thousand rows
with bad timestamps that didn't show up in staging.  ← Part 2: cause

I need either a day of Jin's time to write the
backfill, or we drop the audit-log part of this
release and ship the rest on Friday. Your call.      ← Part 3: the ask

Those three lines are the whole thing. Look precisely at what each part is doing and you get this.

Part 1 answers the other person's first question. The head of someone receiving bad news always runs the same question first. How bad is it, and what do I have to do?

Part 2 answers the next question. What matters here is writing only facts. We did our best, but and unexpectedly are not facts, they are evaluations. That forty thousand rows had bad timestamps is a fact.

Part 3 is what turns this message from a report into a request. Without part 3, the other person receives only bad news and does not know what to do with it. Attach options to bad news and it stops being an incident report and becomes a decision request.

Everyday reporting: the strength of your status vocabulary

To deliver bad news well you have to state status accurately in normal times. If the status vocabulary is mush, nobody notices when a real warning arrives.

The one people get wrong most often here is blocked. Saying you are blocked means there is nothing left that you can do from your side. If there is still something to try, that is slowed or at risk. Overuse blocked and nobody hurries when you really are blocked.

In British-influenced and large-enterprise settings the RAG convention — red, amber, green — is also common. In that case, unless the team agrees in advance on the threshold for going from amber to red, the labels stop meaning anything.

And there is one thing to make explicit. Writing on track when the schedule does not hold is the most expensive sentence on a project. This is not politeness and it is not consideration. The purpose of a status report is to let other people choose while there is still time, and reporting late destroys those choices. A fact that will surface on Friday, said on Tuesday, creates three days; said on Friday, it leaves nothing.

Here is a simple three-line reporting frame as well.

The yesterday, today, blockers format of a daily standup has the same structure. And honestly, of the three lines, the one other people actually need is the blockers line.

Flagging risk early

An early warning is an extremely valuable act, and most of them come out in the wrong shape. A sentence like I'm a bit worried is not information, because the recipient cannot tell what to do with it.

A good risk signal has a condition, a date and an impact. The shape is: if X does not happen by Y, then Z is at risk.

Early warning, not an escalation is extremely useful in practice. A manager who receives an early warning and immediately goes into response mode often makes the situation bigger, and this one phrase prevents that.

The last sentence is worth making a habit too. Promise the next update point along with the warning and the other person does not have to keep asking until then. Attach an update schedule to a warning and the other person's anxiety turns into a manageable calendar item.

Saying you are blocked without sounding helpless

Say only I'm stuck and you look like someone who needs help. Describe the same situation differently and you look like someone in control of it. The difference is not attitude, it is whether you said all four pieces.

What you are blocked on, what you have already tried, what would unblock it, and what you will be doing in the meantime.

This is exactly the principle from the earlier article. I can't do it is a sentence about me; I'm blocked on X is a sentence about a dependency. The second cannot be argued with and does not evaluate me.

Saying how much time you have spent is useful too. Knowing you have spent an hour lets the other person gauge severity. Some teams have an explicit rule that you ask after being stuck for a set number of minutes, but this varies by company, so on a new team it is worth asking what the convention is.

A help request that gets answered

A help request has a fixed shape too. What, how long it takes, what you have tried so far, and by when. With all four present, your acceptance rate is measurably different.

The reason is simple. Given only Can you help me?, the other person has to estimate the cost before answering. They cannot estimate it, so they defer. Say ten minutes and there is nothing to estimate, so the answer comes straight back.

a second pair of eyes is an extremely common idiom in English-speaking workplaces. It asks for a review without putting the other person on a pedestal as the expert, and it costs them nothing to accept. You use it for code, documents and contracts alike.

The last sentence is good too. Cut the scope of the request in advance and the other person does not have to worry that picking this up will cost them two hours.

For reference, there is the phrase sanity check, common in the tech industry. It means the same thing, but a growing number of organisations now classify it in their writing guidance as a phrase to avoid, and use sense-check or double-check instead. Have a look at your company style guide.

Owning a mistake

This section is the most important one in the article. And here more than anywhere, the principle comes before the phrases.

The default is taking responsibility. The skills that make English softer are not for blurring a mistake. A blurred report is easier in the short run, comes back twice as expensive, and above all it steals time from the people who have to fix the problem.

The standard order for owning it is this. What happened → impact → current state → next steps. Prevention goes on after the fire is out.

The weight of an apology has to match the size of the actual damage. Repeat heavy apologies over trivia and you have none left for the big one; go the other way and wave off real damage with My bad and you look like someone who has not understood the damage. My bad for an outage that reached customers is definitively too light.

Speed matters as much as the sentence. One line sent now beats ten minutes spent building a perfect sentence.

I broke the build on main. Rollback is running, ETA about ten minutes.
Nothing to do on your side — I'll post when it's green.

There is a subtle but important distinction here. Many teams now aim for blameless postmortems, and so they use system-focused language. A sentence like the deploy pipeline allowed a config change without review is not evasion; it is a good sentence pointing at something that genuinely has to be fixed.

But the moment that language replaces what you did, it becomes evasion. The two can be used together.

I pushed the config change without review — that's on me.
The pipeline also allowed it, and I think we should close that gap.

The second sentence earns trust because the first one is there. Swap the order and the same two sentences read as an excuse.

The other direction: receiving someone else's bad news

This section is less a list of phrases than a story about a one-sentence habit.

How you react when a colleague brings you a problem early decides when that person will tell you next time. If your first reaction is interrogation, the next piece of news will definitely arrive late. This is not a matter of personality, it is learning.

Thanks for flagging is the heart of this table. It is a two-word sentence, and because it rewards the act of early warning immediately, it genuinely changes how fast a team reports.

What not to do as a first reaction is equally clear. Why didn't you tell me sooner? and Who did this? fix nothing right now and only delay the next report. If you really need questions about process, ask them after the fire is out, and aim them at the procedure rather than the person.

Delivering bad news to customers and executives

I want to emphasise the second-to-last sentence. Do not invent a date you do not know. A date made up to end the conversation reassures the other person in that moment, but when you miss that one too, what breaks this time is not the schedule but the trust. Saying you do not know and promising by when you will find out is uncomfortable in the short run and overwhelmingly advantageous in the long run.

I'd rather tell you now than on the 30th is a good sentence too. Because it puts a name on the act of reporting early, the bad news gets reframed as evidence of diligence.

Things better left undone

Putting the conclusion last. The point of this whole article.

Making bad news sound small. Write a two-week delay as a slight delay and you lose twice. Once when they learn the real size, and then continuously, with every subsequent report doubted.

Hiding the actor in the passive voice. The config was changed and Mistakes were made are textbook cases of responsibility-dodging speech in English. Write who did it.

Ungrounded optimism. It should be fine is something you say only when you have checked. If you have not checked, I haven't verified that yet is the accurate sentence.

Stacking hedges. Pile softeners on bad news and the reader imagines something worse than it is. One layer is enough.

As you know and As I mentioned last week. When something is late, these read as pushing responsibility onto the other person.

Over-apologising. When the apology gets long, the other person ends up having to comfort you. The subject of the conversation then moves from the problem to your feelings.

Declaring it fixed before verifying. Say It's fixed twice and the trust damage exceeds the original outage. The rollback is done — I'm verifying now is the accurate version.

Sending bad news on a Friday evening. Even with no such intent, it looks like burying it. If it is not urgent, Monday morning is better; if it is urgent, it should go now, not late on Friday afternoon.

Adding blame for someone else. Put only facts and next steps in the first message. Even where responsibility does need apportioning, that is the job of the postmortem, not of the incident report.

A worked example: when the schedule slips

(Tuesday morning, team channel)

Me:   Heads-up on the payments release: Friday is at risk.

      What changed: the migration found ~40k rows with bad
      timestamps. Staging didn't have them.

      Where we are: I've got a backfill script drafted, untested.

      What I need: either a day of Jin's time to test it, or
      we drop the audit-log piece and ship the rest Friday.

      Nothing needed from anyone else right now. I'll update
      Wednesday 2pm either way.

PM:   How confident are you in the 40k number?

Me:   That's a count from a query I ran this morning, so the
      number is solid. What I haven't verified is whether the
      backfill handles the null case. I'll know by tonight.

(Wednesday afternoon)

Me:   Update as promised. Jin and I tested the backfill —
      it works, but it takes six hours to run.

      So: Friday is now a slip, not a risk. Realistic date is
      Tuesday the 24th.

      I don't want to give you a Monday date I don't believe.
      Tuesday I do believe.

PM:   Fine. Anything you'd do differently?

Me:   Yes — that's on me. I built the staging dataset from a
      clean export instead of a production snapshot, so the bad
      rows were never going to show up. I'll switch staging to
      a sampled snapshot this sprint.

Here is what was done. The conclusion came first, the cause was given as fact, the ask came with options, the next update point was promised, what was known was separated from what was not, no date was given that was not believed, and at the end the responsibility was pointed at directly. No sentence in it puts the speaker down, and no sentence in it dodges responsibility.

Try this today

1. The first line of bad news: write the conclusion as one sentence first and hang the rest underneath it.
2. One early warning sentence: Flagging early: if X isn't done by Wednesday, Friday is at risk.
3. The four pieces when blocked: on what, what you tried, what you need, what you will do meanwhile.
4. Honesty when you do not know: I don't have a date I'd trust yet. I'll have one by Thursday.

Delivering bad news well does not mean saying it gently; it means saying it accurately while the other person can still do something about it.

Read next

• Office English in email and chat — the previous article. How the first three lines set the tone.
• Small talk at work in English — the next article. Not reporting, just talking to people.
• Writing Practice — conclusion-first writing only sticks after you have written a few by hand.
• Persuasion Lab — attaching options to bad news is, in the end, designing a decision.