Effective observability depends on aligning how we observe three areas: what a change to a system does, what is achieved by it, and what is gained. When these perspectives drift apart, people work in isolation and make decisions that don't add up over time. Part 1 focuses on the doing perspective.

For any change, the three perspectives must stay connected:

• System behavior — what the change actually does inside the system (part 1).

• User/agent outcomes — what people or automated agents can achieve with the change (part 2)

• Organizational value — what the organization gains as a result of changes (part 3)

True observability only works when these three perspectives are measured and interpreted together.

When teams measure only one of these layers — or measure them inconsistently — they drift into siloed decision‑making.

• Engineers optimize system metrics.

• Product teams optimize user outcomes.

• Leadership optimizes business KPIs.

Without alignment, teams can feel like they're doing well while the overall outcome drifts. For me, alignment mostly comes from direct communication in a shared context, and that tends to lift productivity more reliably than any tool or framework. It's a base stat — raise it a little, and everything else improves a little too.

This is the "decisions that don't add up over time" part:
Local optimizations accumulate into global dysfunction.

Edited 2026-05-16

1. Observable Expected Effect

There's absolutely nothing novel to be found here. The real question is why obvious mistakes persist. I made the content deliberately general and childish to illustrate the simplicity of the topic.

Red flag: Doers lose interest the moment a ticket is checked off. There's no change‑specific follow‑up to see how the work actually behaves in the target environment.

Observable & Expected

Trench dug along the street exposing old corroded pipes, with dirt piles, road surface disruption, safety barriers, and workers supervising the pipe removal 

These are the planned, visible consequences of the work that everyone can see and anticipate.

Observable & Unexpected

The excavator bucket accidentally strikes a fiber optic cable conduit that was not marked on utility maps. Severed cables and sparks reveal infrastructure damage that nobody anticipated.

This effect is visible once it happens but was not expected or planned for. Lesson learned?

Unobservable & Expected

Beneath the surface, the excavation silently alters groundwater flow patterns. Water seeps in new directions through disturbed soil layers, pooling in unexpected underground paths. This is a known problem in the area!

These changes are completely hidden from workers above and may only become apparent much later through secondary symptoms like soil settlement. Are there no ways to mitigate the risk?

Unobservable & Unexpected

Deep underground, vibrations from the excavator cause a hairline crack in a nearby gas main running parallel but deeper than the work zone. A small gas leak seeps into surrounding soil.

This is the most dangerous category: invisible damage that nobody anticipated, potentially discovered only after serious consequences emerge. Will you be able to connect the dots later?

Summary

Your profession doesn't matter — excavator operator or software engineer. If you're the one doing the work, you need a fast, reliable feedback loop for each traceable change to see whether reality matches what you thought you were doing at the time. 

It means, 

1. before you press the button, ensure you will capture the expected effect
2. when you have an unexpected effect, you have a learning opportunity
3. when you have an adverse consequences later, you help out fixing and learning

Goal for doers: make output predictable by shrinking the gap between stated intent and observable result — that is, improving conformity with specification over time.