Asking People
A stakeholder, a senior, a provider's support desk: each can answer in minutes what would take you days — if the question arrives with what they need. Bring the expected, the actual, the evidence and your hypothesis, so the answer is usable and so the asking is not delegating your understanding.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
When the fastest route to an answer is another person, what do you bring so that their answer is usable — and so that asking does not replace your own understanding?
The provider's confirmation is not arriving in your test environment. You have spent a morning on it. There is a senior on the team who has done this integration and a support address at the provider, and you are stalling on both because "it doesn't work" feels like an embarrassing thing to send, and because part of you thinks asking is giving up.
Either keep going alone until it is fixed, or send "hi, webhooks aren't working for me, any ideas?" to whoever is nearest. The first protects your pride; the second offloads the problem. Both feel like the reasonable thing to do with a morning already gone.
"It doesn't work" gets the reply it deserves: "what doesn't work?" A round trip is spent establishing what you could have written in the first message, and the senior now has to reconstruct your morning from scratch.
- "It doesn't work" gets the reply it deserves: "what doesn't work?" A round trip is spent establishing what you could have written in the first message, and the senior now has to reconstruct your morning from scratch.
- Support at the provider answers the generic question generically — a link to the getting-started page you have already read — because the message gave them nothing specific enough to look up.
- The senior fixes it at your keyboard in ninety seconds and you learn that they are good, not what was wrong. The next time the confirmation does not arrive, you are back at the same morning.
- Going alone "to avoid bothering people" spends a day of yours to save five minutes of theirs, which no team would choose if asked — and the design decision waiting on the answer waits with you.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Prepare the question the way you would prepare a bug report, because that is what it is — even when the "bug" is in your understanding. Four things: what you expected to happen, what actually happened, the evidence (the exact request, the log line, the status code, the configuration), and your current hypothesis. The first two make it answerable; the third makes it checkable; the fourth makes the answer teach you something, because it can be compared with what you thought.
- Choose the person by what they can see that you cannot. A stakeholder can see the requirement behind the requirement; a senior can see the pattern across integrations; the provider's support can see their side of the boundary — their logs, their delivery attempts. Send each the version of the question that uses their view.
- Ask for the mechanism, not the fix. "What would cause the provider not to attempt delivery?" gets you a model; "can you make it work?" gets you a working test environment and no model. The rule from Reading the Error Message applies to people: read the whole answer, and ask what it rules out.
- Afterwards, close the loop in writing: what the answer was, whether your hypothesis was right, and what you would check first next time. That last line is the difference between having been helped and having learned.
The same problem, asked three ways
The ladder for a question to a person has the same rungs as the ladder for a question to documentation — component, boundary, mechanism, scope, decision — plus the four lines that let another person check it. The vague form below is what the morning produced; the best form is what the senior can answer in one line and what you can learn from.
why The best form can be confirmed or corrected in one reply, and it teaches something either way: if the hypothesis is right you learn the delivery-log habit; if it is wrong you learn exactly which of your four lines was mistaken. The vague form invites a clarifying question; the better form invites a list of causes with no way to pick between them.
What to bring, decomposed
The four lines are a decomposition of "a usable question", and each leaf has a test: could the answerer act on it without asking you anything? The tree is the same whoever you are asking; what changes is which leaf carries most of the weight.
- ├Expected— says which behaviour you were relying on
- └The behaviour and its sourcetestable Names the documented or assumed behaviour — "the provider calls my URL after a payment" — and where you got it, so the answerer can check whether the expectation itself is wrong.
- ├Actual— the gap the answer has to explain
- └The observation, not the interpretationtestable "No inbound request in the access log for ten minutes" rather than "webhooks are broken"; a reader can distinguish an observation from a conclusion.
- ├Evidence— what makes the answer checkable
- └Identifierstestable Payment id, timestamp, endpoint URL — anything a provider could type into their own search.
- └What you ruled outtestable One line per attempt — "endpoint responds to a hand-made request" — so the answerer's first three suggestions are skipped.
- ├Hypothesis— what turns the answer into learning
- └A falsifiable guesstestable States a cause the answer could confirm or refute — "the provider cannot reach localhost" — not "something is wrong with the config".
- ├The ask— what you want back
- └Mechanism or decision, scopedtestable Asks for a cause or a choice ("which of these two designs?"), not for the problem to be taken away; fits in one reply.
For a stakeholder, "Expected" and "Actual" become "here is what I understood you to need" and "here is the consequence of each design"; the shape holds.
The message, before and after
Two messages to the provider's support about the same missing confirmation. The first is what the morning produced; the second took ten minutes to write and is answered in one reply with a design consequence attached.
Hi, one of our webhooks didn't arrive in test mode. Is there something wrong on your side? Thanks.
Payment pay_… created 14:02 UTC (test mode). Expected: one delivery to https://…/webhooks/payment. Our logs: one attempt at 14:02 answered with 500 by us (our bug, fixed), no further attempts in the following hour. Question: does your retry schedule apply in test mode, and can you show the delivery attempts for this payment id? We are deciding whether our order state must tolerate a confirmation arriving well after checkout.
The second message carries a key support can search on, an observation they can compare with their own logs, and the decision that waits on the answer — so the reply is specific, checkable, and immediately usable in the design. The first message can only be answered with a question.
How to do it
Most important first.
- Before asking anyone, write the four lines — expected, actual, evidence, hypothesis. If you cannot fill "evidence", you are not ready to ask; go and get one log line (Logs Are Evidence, Not Thinking).
- Say what you have already tried and ruled out, in one line each. It saves the answerer's first three suggestions and shows them where the search is.
- Scope the ask: "I need to know whether the provider attempted delivery" is answerable in a minute; "help me with webhooks" is not.
- For a stakeholder, bring the two designs the answer chooses between, in their language: "if guests can check out, the cart lives in the browser session; if not, it lives on the account — which do you need?" (Goal vs Implementation).
- For a provider, bring identifiers they can search for — the payment id, the timestamp, the endpoint URL — and the exact error. Their support is a lookup service and it needs a key.
- Write the outcome down before the day ends, next to the hypothesis you had. Then ask yourself the one question the helper could have asked you: "what would you check first next time?"
Worked on a concrete problem
The move has to produce something. This is what it produced.
- To the senior: "Expected: after a test-mode payment, the provider calls /webhooks/payment within a few seconds. Actual: no request reaches the endpoint; the payment shows succeeded in the dashboard. Evidence: server access log shows no inbound request at all for ten minutes; the endpoint responds to a hand-made request; the dashboard's webhook page lists the URL as http://localhost:3000/… Hypothesis: the provider cannot reach a localhost URL, and I need a tunnel or a deployed endpoint. Have I got that right, or is there a delivery log on the provider side I should check first?" The senior's answer is one line and confirms the hypothesis, plus the thing you did not know: the provider's dashboard has a delivery-attempts view that would have shown the connection failure. Next time you check that first.
- To the provider's support, later, when the tunnel works but one confirmation is missing: "Payment id pay_…, created at 14:02 UTC. Expected one delivery to https://…/webhooks/payment. Our logs show one attempt at 14:02 with our 500 response (bug on our side, since fixed) and no retry. Does your retry schedule apply to test mode, and can you show the attempts for this payment id?" Support can search by the id, the answer is specific, and it settles a design question — retries do apply and are spaced out, so the order must tolerate a late confirmation (Webhook Retries and Ordering in Backend covers the schedule).
- To the founder: "Two designs depend on one answer. If a customer must have an account to order, the cart belongs to the account and survives devices. If guests can order, the cart belongs to the browser session and is lost when they switch devices — but nobody is turned away by a sign-up form. Which matters more to you for launch?" The founder chooses guests; the cart schema is decided; and the reason is recorded next to the decision so it can be revisited (The Decision Journal).
How you know it worked
What now exists that did not before, and what question you can now ask.
- Your message can be answered in one reply, and the reply either confirms or corrects a hypothesis you had written down.
- The answerer asks no clarifying question, because the evidence was in the message.
- After the answer you can name the mechanism, not just the fix, and you know what to check first next time.
- The stakeholder chose between designs you described in their words, and you wrote down why.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What did I expect, what actually happened, and what is my one piece of evidence?
- ?Who can see the side of this boundary I cannot, and what identifier do they need to look it up?
- ?What is my hypothesis, and what would the answer have to be to prove it wrong?
- ?After the answer — what is the mechanism, and what would I check first next time?
What can go wrong
- Over-preparing as avoidance. The four lines become a document, the document takes the afternoon, and the person who would have answered in a minute is never asked. If the four lines are more than a screen, you are hiding.
- Asking without a hypothesis. The answer arrives and teaches nothing, because there was nothing to compare it with. "I have no idea" is honest but it is not a hypothesis; "I think it is the URL" is a hypothesis even when wrong.
- Asking the wrong viewer. Sending the provider a question about your stakeholder's requirement, or the founder a question about retry schedules. Each person can see one side of one boundary; match the question to the view.
- Accepting the fix and skipping the mechanism. The senior types the tunnel command; you thank them; the model of "the provider must reach a public URL" is never formed, and the next environment breaks the same way.
- A well-prepared question costs you time before it costs the answerer any. On a trivial question that is the wrong trade; the skill includes knowing when a one-line "which file is the webhook handler in?" is the right message.
- Bringing a hypothesis invites being wrong in front of someone. It is also what makes the answer stick, and most seniors would rather correct a hypothesis than construct one.
- Asking early and well can mean never developing the debugging stamina that solving it alone would have built. The balance is a time box: an honest attempt, then the four lines, not a day of pride.
- "Asking for help is delegating understanding." Asking "can you fix it?" is. Asking "here is what I expected, here is what happened, here is my evidence and my hypothesis — where am I wrong?" is the opposite: it is understanding, presented for review. The manifesto's line is about what you keep, and a hypothesis is yours.
- "Support desks are useless." They are lookup services with access to the other side of the boundary; they fail on vague questions and are remarkable on specific ones with an identifier attached. The quality of the answer tracks the quality of the key.
- "Stakeholders do not understand technical trade-offs." They understand consequences. "Guests can order but lose their cart when they switch devices" is a consequence; "session-scoped cart" is not. Translate and they decide well.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALExpected, actual, evidence, hypothesis is the shape of any usable question to a person, a support desk or a bug tracker; what changes is which of the four the audience most needs (a stakeholder needs the consequence, a provider needs the identifier).
- TEAM-SPECIFICOn a team with a senior who has done the integration, the honest time box before asking is short — an hour, perhaps — because their minute is cheap and your day is not; a solo learner with no one to ask has a longer box and the provider's support and community as the only people, which makes the identifier discipline matter more.
- ILLUSTRATIVEThe localhost webhook, the missing retry, the ten-minute log window and the founder's guest-checkout choice are invented; real providers differ in retry behaviour and dashboard features, and the message is the shape of the ask, not a description of any product.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "Review the LLM's answer" route at /manifesto/review is the same discipline pointed at a machine: expected, actual, evidence and a hypothesis are what you bring to an AI as well, and what a fluent answer is checked against.