Human Judgment Across the Software Delivery Lifecycle
Judgment should challenge assumptions during planning, define invariants in architecture, test evidence at release, interpret novelty during incidents, and convert outcomes into systemic learning after recovery. Human judgment is valuable precisely where a system cannot reduce the decision to a stable rule without losing context, authority, values, or accountability. It should not become an ornamental approval step or an excuse to leave unsafe automation unbounded. The control must be designed around the actual decision and its consequences.
01.A Predictable TinyCTO Incident
Planning approved the shortcut, architecture hid the dependency, release accepted a green check, operations inherited the surprise, and the postmortem asked which engineer clicked deploy. The failure is not that a human disappeared from the interface. The failure is that intent, evidence, authority, reversibility, and accountability stopped travelling together. A polished workflow can therefore remain procedurally correct while becoming operationally wrong.
02.The Governing Principle
Human judgment is distributed across the lifecycle, but accountability must remain connected. Each stage should produce evidence and decision boundaries that the next stage can actually use. This distinction matters because automation changes the economics of decisions. It can repeat a useful action at enormous scale, but it can also repeat an invalid assumption faster than an organization can notice. Good judgment does not compete with automation; it defines the safe operating envelope in which autonomy is earned.
03.What Good Implementation Looks Like
- Planning: test assumptions, incentives, ownership, and hidden dependencies. - Architecture: define invariants, failure boundaries, degradation, and recovery. - Release: demand executable readiness evidence and a credible rollback path. - Incident response: authorize adaptation when the documented path no longer fits reality. - Postmortem: examine controls, decisions, workload, incentives, and recovery without convenient blame. These controls must be visible at runtime. A policy document that cannot stop, narrow, explain, or reverse system behavior is not an operational safeguard. Teams should test the path under realistic time pressure, incomplete evidence, unavailable reviewers, and partial failure.
04.Common Failure Modes & Anti-Patterns
- Each stage optimizes its own green metric. - Handoffs transfer conclusions but lose uncertainty. - Release authority is detached from operational accountability. - Postmortems correct people instead of system conditions. The recurring anti-pattern is responsibility without agency: a person is named accountable after the system has hidden evidence, removed time, narrowed options, or completed the action. That is not meaningful human oversight. It is liability routing.
05.Practical Review Framework
1. Who owns the objective and who may override the system? 2. What evidence, uncertainty, provenance, and alternatives are visible? 3. What is the worst credible consequence, and is the full outcome reversible? 4. When must the system pause or escalate? 5. How will the decision and its outcome improve policy, evaluation, and design?
JUDGMENT MUST SURVIVE THE HANDOFF > Every stage approved the release. Production was the first reviewer with complete context.