Week 35 Day 3: The Minimum Viable Process -- Start Light and Add Weight Only When Needed

Heavy process is easy to create and hard to remove. Once a three-step approval chain is in place, removing it requires convincing everyone in the chain that their step is unnecessary. The person at each step has an incentive to keep it because it justifies their involvement. Light process is easy to create and easy to evolve. A one-page checklist can be updated in 10 minutes. A three-step approval chain requires a committee to change.

Here is the minimum viable process (MVP) approach to process design. Step one: identify the specific failure mode you are trying to prevent. Not 'deployment failures' in general -- 'deployment failures caused by configuration drift between environments.' The more specific the failure mode, the lighter the process can be. Step two: design the lightest intervention that addresses the failure mode. For configuration drift, the lightest intervention might be: 'Before deploying, run `diff` between production config and staging config. If there are differences, review each one and confirm it is intentional.' That is a one-sentence process. It takes 30 seconds. It prevents the specific failure mode. Step three: implement the process and observe. If the one-sentence process prevents the failures, stop. You are done. If failures persist despite the process, diagnose why. Did people skip the process? (Compliance problem -- make it easier or automate it.) Did the process catch the wrong things? (Design problem -- refine the check.) Did a new failure mode appear that the process does not cover? (Scope problem -- add a targeted check for the new failure mode.) Step four: add weight only in response to documented failures. Never add weight preemptively ('what if someone does X?'). Only add weight in response to evidence ('someone did X and it caused Y'). This ensures every element of the process earns its place. Here is an anti-pattern I see frequently. A team experiences one deployment failure. The response is a 15-point deployment checklist, a mandatory peer review for all deployments, a deployment window restriction, and a post-deployment monitoring requirement. This heavy process might be appropriate for a team with a history of serious deployment failures. For a team that had one failure, it is massive overkill. The MVP approach would start with a single check targeting the specific cause of the one failure, and add weight only if additional failures occur.

The minimum viable process approach implements what lean methodology calls 'just-in-time' process design (Womack and Jones, 1996) -- creating process elements only when they are needed and only to the degree needed. Research by Poppendieck and Poppendieck (2003) on lean software development demonstrates that 'just-in-time' process design produces outcomes equivalent to heavy upfront process design with 30-50% less overhead, because it avoids the waste of creating process elements that address hypothetical rather than actual risks. The 'add weight only in response to documented failures' principle implements what Taleb (2012) calls 'antifragile' design -- systems that improve in response to stressors rather than attempting to predict and prevent all possible stressors in advance. The anti-pattern of overreacting to a single failure is documented by March, Sproull, and Tamuz (1991) in their research on 'learning from samples of one or fewer,' which demonstrates that organizations frequently overweight single dramatic events (a deployment failure) and implement disproportionate responses (15-point checklists), while underweighting frequent minor events that cause more cumulative damage. Their research found that the optimal organizational learning response to a failure is proportional to the frequency and severity of the failure, not to the emotional impact of the most recent instance. The 'every element earns its place' principle connects to what Reinertsen (2009) calls the 'economic framework for process design,' which argues that every process element should be justified by a quantified cost-benefit analysis: the expected cost of the failures the element prevents must exceed the ongoing cost of the element itself. Elements that fail this test should be removed.