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.
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:
- One question about the requirement.
- One question about the risk or evidence.
- 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?
- What failure modes could create duplicate notifications, how will you detect or tolerate them, and what rollback path remains after release?
- Use idempotency keys, a feature flag, and the event platform because that is our safest design.
- 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.