Playbook / Technical Leadership

Sensible Defaults

Ten engineering organization defaults that raise the baseline for how teams build and ship software.

Inspired by Thoughtworks Sensible Defaults.

These are not rules. They're defaults — starting positions that should be followed unless you have a good reason not to, and where exceptions require explicit justification.

  1. Integrate frequently and continuously — If you're not integrating at least daily, you're accumulating merge risk.
  2. Code is written with test-driven development — Tests aren't written after; they're written first. This changes how you design, not just how you verify.
  3. Develop in pairs — See Pairing Guidance.
  4. Smallest value-oriented stories — Break work down until each card can be delivered and validated independently. Large cards hide risk.
  5. Security is automated in the SDLC — Security checks run in the pipeline, not as a quarterly audit.
  6. Every code change is monitored and observable — If you can't observe the behavior of your code in production, you don't know if it works.
  7. Build pipelines automate local development — The pipeline should remove friction from running the system locally, not just from CI.
  8. Technical change requires a value proposition — Refactors, upgrades, and rewrites need to be justified in terms of value delivered, not just technical preference.
  9. Deployment is decoupled from release — You can deploy any time. Whether users see the change is controlled separately, via feature flags or equivalent.
  10. Measure quality — Code coverage, static analysis, and other quality signals are tracked and visible.

Supporting Resources

← Playbook