How to ask for a decision at work (and actually get one)

A message gets a decision when it holds exactly one question, one recommendation, and a date after which you will act anyway. Most asks that stall contain none of these. They contain context.

I have watched this from both sides. The asks I send that die are the careful ones. The asks I answer fastest are almost rude in how little they make me do.

Why your ask did not get an answer

Most decision requests fail because they read as updates. The question is in there, somewhere around paragraph four, wearing a question mark, and by then the reader has already classified your message as information. Information can wait.

Watch yourself handle one of these. A message opens with background, you nod along, you feel mildly informed, you move on. Nothing in the first three lines asked you for anything, so you gave it nothing. That was not rudeness. The message introduced itself as reading material, and you treated it accordingly.

Long messages get skimmed, and a skimmed ask gets filed as an FYI. The sender waits for an answer. The reader never heard a question.

Put the question in the first line

Ask one question per message, and put it in the first sentence, before any background at all.

This feels abrupt. Send it anyway. A reader can only relax into your context once they know what job the message is asking them to do. Until then every sentence is suspense, and suspense is work you are billing to someone else's attention.

A decision ask has four parts, in this order:

• The question, first line, phrased so a yes or a no would answer it.
• The two or three facts the reader needs to answer, and none they do not.
• Your recommendation.
• The date you need an answer by, and what you will do without one.

The whole thing should fit on one screen. If it does not, cut facts until it does; the full history can live in a linked doc, at the bottom, where it can do no harm.

Two questions means two messages. It feels fussy, and it means neither question sinks with the other.

Recommend one option

Give the decider a recommendation, not a menu. "I think we should do A, because the migration risk is ours either way. Ok to proceed?" beats a tidy comparison of three options nearly every time.

The balanced menu looks respectful. I think it is mostly a way of avoiding responsibility. You did the analysis, so you hold more context on this choice than anyone you could send it to, and a menu quietly moves the deciding onto the person holding the least.

A wrong recommendation still does its job. The reply that says "no, B, the contract rules out A" took ten seconds to write, and now the real constraint is on the table. The menu never surfaces it, because nobody argues with a table.

There is an exception. When the tradeoff genuinely belongs to the other person, their budget, their scope, lay out the options. Then still say which one you would take. You are allowed an opinion about a decision you do not own; that is what being consulted means.

Name the default, then honor it

End the ask with a date and a default: "If I do not hear back by Thursday, I will go with A." Then, on Thursday, actually go with A.

People worry the default line reads as an ultimatum. Written well, it does the reader a favor: silence now has a small, named cost instead of an unknown one, and nobody has to feel guilty about their inbox.

Three rules keep a default polite:

• Default to something reversible, like starting the work rather than shipping it.
• Leave a real gap, because a Thursday deadline sent Thursday morning is a decision you already made, dressed up as a question.
• Stay inside your own lane, since a default on someone else's budget is a land grab with a timestamp.

The first time you let a default fire, it feels like getting away with something. Let it fire anyway. A default you extend twice becomes a reminder that your dates are negotiable, and people keep surprisingly careful books on that sort of thing.

Confirm the decision where people can see it

A decision that lives in a DM evaporates. When the yes arrives, write one line where the affected people will actually see it: "Decided: going with A, starting Thursday."

The line does two jobs. It makes the decision real, because a choice nobody wrote down gets relitigated in three weeks by someone who was never in the thread. And it protects the person who decided, who said yes on their phone in a hallway and deserves not to be the only witness.

When the answer still does not come

Silence after a good ask usually means bad timing rather than a bad ask, so follow up once, and make the follow-up shorter than the original. One line does it: "Still good with A by Thursday?" I wrote up how to follow up without nagging separately; the mechanics fit in a line and the tone matters more than the timing.

Some silences you cannot chase at all, and they are clarifying. When Unvent sat in Chrome Web Store review, there was nobody to nudge and no default to fire; the queue moved when it moved, and I refreshed the dashboard like it owed me money. Any ask with an actual human on the other end is easier than that. Worth remembering before you resent a quiet inbox too much.

And when a deadline passes, the default quietly ships, and nobody says a word, notice that. Let it happen a few times and a pattern emerges: some of the decisions you have been waiting on were never really pending. They were yours the whole time, sitting in someone else's inbox for safekeeping. The default line is how you take them back.