SkarpSkarp

Chapter 3 of 3

From Solution Giving to Trade-Off Questions

Guide an engineer to evaluate requirements, risks, evidence, trade-offs, and reversibility without prescribing the technical answer.

6 min readen

1. Replace the Answer with a Decision Frame

Move from answers to judgment

A quick answer can solve today's task but create dependence tomorrow. Start by helping the engineer define the decision and the outcome it must protect.

Use a decision funnel

Move from a broad problem to explicit criteria, then to a proportionate experiment or commitment. The goal is visible, testable reasoning.

2. Establish the Non-Negotiables

Find the real constraints

Ask what must be true at release, who owns clarification, and what would make an option unacceptable. Treat precedent as a preference until verified.

Clarify work, authority, and support

AFS 2023:2 has applied since January 1, 2025. It replaced AFS 2015:4 and requires work demands and resources to be appropriately balanced.

3. Case: The Checkout Notification Delay

The tempting answer

A new engineer proposes a queue for delayed notifications. The manager could prescribe the existing platform, but instead asks for evidence and two credible options.

Compare, do not guess

Compare customer impact, failure modes, observability, ownership, delivery time, and reversal cost. A recommendation becomes defensible rather than inherited.

4. Ask for Evidence at the Right Cost

Evidence should be proportionate

Ask what is known, assumed, and uncertain. Then find the cheapest test that could disprove the leading assumption before funding a larger investigation.

Make disagreement evidence-based

In review, distinguish technical evidence from personal preference. When multiple options are equally sound, the engineer can reasonably choose.

5. Practice: Turn Advice into Questions

Rewrite the manager's response

You are reviewing Lina's design note. Your draft reply is: "Use the event platform, make delivery asynchronous, and add retries."

Rewrite it as three questions:

  1. One question about the requirement.
  2. One question about the risk or evidence.
  3. One question about reversibility.

A strong version could be:

  • "What user-visible delay is acceptable if checkout itself succeeds?"
  • "What trace or load-test result would show that synchronous delivery is the bottleneck?"
  • "Which option can we disable or roll back without losing notification intent?"

Pause before offering your view. If the engineer misses a material risk, name the risk, then return responsibility: "I am concerned about duplicate messages. How will each option detect or tolerate them?" This is guidance without taking over the design.

6. Make Reversibility an Explicit Criterion

Define reversal concretely

Ask about data, customer commitments, dependencies, operational burden, and restoring previous behavior. "Can we roll back?" is too vague on its own.

Bound the experiment

Use a flag, limited scope, shadow path, and a stop condition where appropriate. Separating configuration from code can make a change easier to reverse.

7. Close with Ownership, Documentation, and Follow-Up

Record the reasoning

Capture scope, assumptions, options, evidence, uncertainty, rollback, owner, and review date. The engineer owns the record and presents the recommendation.

Use the reflection question

What additional information could change your decision? It separates commitment from certainty and creates a clear trigger for follow-up.

Decision Coaching Check

Choose the best manager response

Lina recommends the asynchronous worker but has not described duplicate-delivery handling or rollback. Which response best coaches judgment without prescribing the implementation?

Which response is strongest?

  1. What failure modes could create duplicate notifications, how will you detect or tolerate them, and what rollback path remains after release?
  2. Use idempotency keys, a feature flag, and the event platform because that is our safest design.
  3. Do more research and return when you know the correct architecture.
Show Answer

Answer: A) What failure modes could create duplicate notifications, how will you detect or tolerate them, and what rollback path remains after release?

The first response identifies material risks and asks the engineer to evaluate safeguards and reversibility. The second gives a solution; the third delegates uncertainty without setting a decision frame.

Key Terms

trade-off
A consequence accepted in order to gain another benefit, such as delivery speed in exchange for operational complexity.
reversibility
The practical ability to undo, disable, or contain a decision after implementation.
decision frame
A concise definition of the decision, intended outcome, constraints, and decision owner.
decision record
A lightweight written account of options, evidence, assumptions, choice, ownership, and review triggers.
unhealthy workload
In AFS 2023:2, a longer-term imbalance where work demands exceed resources and recovery is insufficient.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself