Writing to Learn and Writing to Decide

By the end of this lesson, you will be able to...

• Separate a note that exposes uncertainty from a memo that commits a team to action.

• Turn questions, evidence, and alternatives into a decision with an owner, a trade-off, and a revisit condition.

• Notice when a draft is claiming certainty before it has earned it.

Idea in one sentence: Use exploratory writing to make the unknowns inspectable; use decision writing to state what the team will do despite the remaining uncertainty.

Core Insight

The Parcel import team has a launch in ten days. Two pilot customers have asked for faster processing, so an engineer proposes raising the import concurrency limit from 8 jobs to 12. The last time the team raised the limit to 16, the database connection pool saturated and queue age rose for every customer. The team has new load-test data, but it has not yet tested the pilots' largest files.

Someone opens a document titled Decision: raise concurrency to 12 and starts collecting supporting facts. The title has quietly decided the question. Facts that might make 12 unsafe now look like objections to be answered instead of evidence to learn from.

The opposite failure is familiar too. A page titled “notes” accumulates graphs, questions, and meeting fragments for three weeks. Everyone can see that there is uncertainty; no one can tell what will happen before launch.

These are different writing jobs. The first is writing to learn: it creates a visible model of a question before the team is ready to commit. The second is writing to decide: it records a chosen path so people can act, understand the cost, and know when to revisit it. Calling both documents “a design doc” hides the switch in responsibility.

Plainly: do not make a conclusion sound settled while you are still discovering what would make it safe. But do not leave a group in permanent exploration once it has enough evidence to choose a bounded next step.

Two Modes, Two Promises

An exploratory note promises, “Here is what we are trying to understand.” A decision memo promises, “Here is what we will do and why.” The distinction is not about polish. An exploratory note may be concise and a decision memo may acknowledge uncertainty. It is about the reader's next job.

For Parcel, an honest exploratory opening is:

Question: Can we raise import concurrency for the pilot without making queue age unsafe for other customers?

Known: Eight jobs has stayed below 70% database-pool use in the last two releases. Sixteen jobs caused saturation during the March incident.

Unknown: Whether 12 jobs remains safe when two pilots upload their largest file mix at the same time.

Next evidence: Run the pilot file mix at 8, 10, and 12 jobs; observe pool use, error rate, and queue age for a non-pilot tenant.

That note is useful precisely because it does not pretend to know the answer. It exposes a testable uncertainty and stops a preference—“faster imports would be nice”—from masquerading as a decision.

The named technique is a mode switch. Keep the language of inquiry while the team is learning: question, assumption, unknown, option, test, evidence that would change our view. When a responsible person chooses, switch to the language of commitment: decide, will, owner, accept, do not do, revisit when. A reader should be able to tell which mode they are in without inferring it from a meeting calendar.

Check: Which sentence belongs in the exploratory note rather than the decision memo?

Think first, then reveal.

Answer: “We need to test whether 12 jobs leaves enough connection-pool capacity for a non-pilot tenant.” It names an unresolved condition and a way to learn. “We will keep the limit at 8 for the launch” is a commitment, so it belongs in the memo once the team has chosen.

The Bridge From Learning to a Decision

Do not copy the exploratory note into a memo and delete the question marks. Use the note to decide whether the evidence is sufficient for the scope of the choice. A decision can be narrow: “keep 8 for this launch and test 10 next week” is a real decision, even though it does not settle the permanent limit.

For each candidate option, ask four practical questions:

1. What outcome are we protecting? In this case, fast enough pilot imports without silently harming every other customer's queue.
2. What evidence bears on that outcome? Load tests, the prior saturation incident, and a test of the pilot file mix are stronger than a preference for a round number.
3. What cost are we willing to accept? Keeping 8 means some pilots wait longer; trying 12 now risks shared capacity during a public launch.
4. What observation would make us reopen this? A successful controlled test at 10, or a queue-age breach at 8, gives the future team a concrete trigger rather than a vague promise to “review later.”

This turns writing into a small decision mechanism. Exploration produces candidate paths and evidence. The decision captures the selected path, its price, and the signal that would invalidate it. The memo should link to the note when future readers need the reasoning trail; it should not force an on-call engineer to reconstruct the choice from raw brainstorm fragments.

Here is the transition after the team runs the test. At 12 jobs, pool use peaks at 88% and a non-pilot tenant's queue age reaches nine minutes. At 10, pool use peaks at 74% and queue age stays below three minutes. The launch target is a queue age below five minutes.

The naïve alternative is, “Raise the limit to 12 because the pilots asked for speed.” It contains a desired outcome but no operational boundary. It cannot tell an operator what harm is acceptable, who can reverse the change, or what result would show the plan was wrong.

A Decision Memo That Can Be Used

The resulting memo can be short because the learning work has already happened:

Decision: Keep the production import concurrency limit at 8 for the public launch. After launch, pilot 10 jobs for two named customers behind a reversible flag.

Evidence: In the representative load test, 12 jobs produced nine minutes of queue age for a non-pilot tenant, above our five-minute target. Ten jobs stayed below three minutes. We do not yet have production evidence for the pilots' largest simultaneous uploads.

Trade-off: Pilots will not receive the fastest possible imports during launch. We accept that delay to avoid transferring capacity risk to other customers.

Owner and next action: Mira, the import-service owner, enables the two-customer pilot and verifies the dashboard before each increase.

Revisit condition: Consider 10 as the default only after seven days below the queue-age target; roll back immediately if queue age exceeds five minutes for two consecutive intervals.

Notice what the memo does not say. It does not claim that 10 is universally safe. It states the scope—two customers after launch—and names the evidence and condition under which the choice changes. That is enough certainty for coordinated action without invented certainty about the system.

The same shape works outside service operations. An architectural choice can record an untested scaling assumption. A documentation team can decide to deprecate a page while preserving the open question about migration needs. A writer choosing an analogy can first explore where it breaks, then decide whether its explanatory gain is worth that boundary. The vocabulary changes; the mode switch does not.

Check: A memo says, “Adopt option B; it is simpler.” What is the smallest addition that makes it a usable decision record?

Think first, then reveal.

Answer: Add evidence, the cost the team accepts, an accountable owner, and a revisit condition. For example: “Adopt B because it removes the migration step; accept slower first import; Noor owns rollout; revisit if setup failures exceed 2%.” “Simpler” alone does not tell a future reader simpler for whom, at what price, or when the judgment fails.

Trade-offs and Failure Modes

Exploratory writing has a cost: it can feel untidy and can delay a commitment. Use it when the uncertainty could change the action or when people are arguing from different implicit models. Do not demand a full exploration before a reversible, low-risk action; an incident runbook often needs a direct command, not a miniature research paper.

Decision writing has the opposite cost: compression can conceal an unresolved risk. A crisp memo becomes dangerous if it omits the evidence gap, presents a temporary choice as permanent, or loses its link to the exploratory work. It is not a marketing announcement for the winner of a debate.

Watch for these failure modes:

• Premature title: “Decision: choose 12” biases the note before the evidence is listed. Start with the question instead.
• Evidence laundry list: A long set of links is not exploration unless each item can change an option or test an assumption.
• Permanent maybe: “We should consider…” preserves ambiguity after someone needs a coordinated action. State the owner and the next move.
• Unowned decision: “The team decided” does not identify who implements, verifies, or can reverse the choice.
• False finality: A decision without a condition for review treats a time-bounded judgment as a law of nature.

The boundary is simple. An exploratory note is not an excuse to avoid responsibility; a decision memo is not proof that uncertainty has disappeared. Good technical writing makes the handoff between learning and commitment legible.

Practice

Pick a live choice that is small enough to reverse: a default value, a documentation route, a rollout order, or a team convention. First write an exploratory note with exactly five labels: Question, Known, Unknown, Options, and Next evidence. Do not write a recommendation yet.

Then imagine you have gathered one useful result. Write a five-part memo: Decision, Evidence, Trade-off, Owner, and Revisit condition. Compare the two documents. If the memo merely repeats open questions, you have committed too soon. If it makes a move but cannot say why it is safe enough or when to reopen it, it is only an assertion.

For a final transfer test, give the memo to a colleague who did not attend the discussion. Ask them to answer three questions without asking you: What will happen next? What downside did we accept? What observation changes the plan? Any missing answer points to the document role that needs more work.

Resources

• [GUIDE] AWS architectural decision record process — Focus: Record a decision, its context, consequences, and later supersession in a durable form.
• [GUIDE] Google Engineering Practices — Focus: See how written design and review practices make technical reasoning inspectable before implementation.
• [GUIDE] Google SRE: Postmortem culture — Focus: Practice stating evidence, contributing conditions, and follow-up actions without replacing inquiry with blame.

Key Takeaways

• An exploratory note names the question, evidence gaps, options, and next learning step; it should not smuggle in a conclusion.
• A decision memo commits to a scoped action while preserving the evidence, trade-off, owner, and condition that could reopen it.
• The transition from learning to deciding is a change of reader promise, not merely a cleanup pass on the same draft.
• A decision can be responsible without being permanent when its rollback and revisit conditions are explicit.