The Rule
After your change is approved and enters the delivery pipeline, you should be able to forget it.
No following it through pipelines. No watching for when it lands. No manual checking for failure states.
Pain Point
Tracking deployments “just in case” creates unnecessary cognitive load.
It turns delivery into a background worry: tabs left open, dashboards checked, attention fragmented.
If something requires attention, you should be told.
Do
Treat delivery as a system property:
- Push “surprises” left: run fast, automated cross-system checks (e.g. integration tests) before merge, at code-review time, to minimise post-merge failures.
- You should get a signal if something is blocked or broken.
- You should not need manual reassurance.
- When the system is healthy, silence is expected.
(see No News Is Good News).
Do Not
- Follow a deploy through the pipeline to feel safe.
- Keep checking “did it land yet?”
- Watch logs/dashboards after merge for reassurance.
Scope
This is for routine, continuous delivery of typical changes.
This does not cover:
- major migrations
- one-way / high-blast-radius changes
- communicating expected delivery times (ETAs)