The anatomy of a good observation

People make decisions from evidence all over an organization. They choose what to notice, interpret what it means, and decide how much confidence to place in it. That act of observation is subjective, so the result can be partial, biased, or simply wrong. Readers can then inherit the writer's blind spots when they act on it.

A good observation makes the evidence, the interpretation, and the limits of that interpretation explicit. It gives a decision-making process something quantitative and qualitative to work with, instead of asking people to fill in the gaps themselves.

I taught this framework to the observability team at Norwu back in 2018. We wrote for engineers and managers who needed to decide whether to invest, escalate, wait, or change course. They had different technical backgrounds, but very little time to reconstruct an argument from a chart.

Our reports improved when each observation carried enough reasoning for another person to use it without reconstructing the argument from scratch. The framework below is the small quality bar we used to get there.

What a good observation is

An observation explains measured evidence in context.

It tells the reader what happened, what the evidence means, and why it matters.

When the evidence supports it, the observation may also state a conclusion or recommend a next step.

A good observation can move a decision forward. The decision flow makes that relationship explicit:

Each part has a distinct job. Measured evidence establishes the facts. A good observation interprets those facts and connects them to a consequence. The decision chooses the responsible response. Sometimes the response is action. Other times, the evidence supports investigation or continued monitoring.

Possible responses

The traits of a good observation

I use six traits as the quality bar. The first three describe what every observation needs: it must be grounded, clear, and relevant. The other three are conditional. Add visual support, a supported conclusion, or a recommended next step when the evidence gives that addition a clear job.

Required traits

The required traits describe the minimum shape of a useful observation. They are independent qualities, not steps in a sequence.

Conditional traits

Conditional traits add support around the core observation. They are options, not requirements to apply mechanically.

What the required traits do

A grounded observation gives the reader enough measured evidence to verify the claim. For a metric, include the value, unit, aggregation, and time window. A statement such as "the service processed 240 requests during the last hour" can be checked. "Usage increased" leaves most of the measurement undefined.

A clear observation explains the evidence in plain English without erasing technical nuance. Specialized terms can stay when they are useful, but the reader should not have to know them in advance. Define the term, then explain what it changes about the interpretation.

A relevant observation connects the technical result to a consequence. The consequence may affect users, system reliability, operating cost, or a business commitment. This context is what makes the evidence useful to someone making a decision.

What the conditional traits do

Visual support belongs when a chart or diagram reveals something that prose would make harder to see.

A supported conclusion belongs when the evidence justifies a firm interpretation.

A recommended next step belongs when the observation gives the team enough confidence to act or points to a responsible investigation.

Conditional traits should earn their space. Adding all three by default makes reports longer without making them clearer.

When to include a visual

Use a chart when the shape of the data matters. Distributions, changes over time, and comparisons are usually easier to judge visually.

Use a diagram when the reader needs to understand a sequence, relationship, system boundary, or decision path.

Skip the visual when it only repeats one number or restates the paragraph beside it. The reader should learn something from the image that would otherwise take more effort to understand.

Always introduce the visual before it appears and explain the relevant pattern afterward. A chart dropped into the middle of a report without interpretation pushes the analytical work back onto the reader.

From metric to observation

The general model becomes concrete with a familiar latency example. A checkout service is responding slowly for some customers, and the team has to decide whether to investigate, change the system, or keep watching it.

The evidence at hand

The available evidence covers the last 30 minutes of checkout requests. The average response time is 2.5 seconds, the P95 is 17.8 seconds, and the distribution looks like this. At this point, we have measured evidence, not an explanation.

Response time distribution (illustrative)

Metric	Value (%)
0-1s	32
1-2s	33
2-3s	22
3-5s	5
5-17.8s	3
17.8s+	5

The chart gives us measured evidence and a useful shape. It does not establish a cause or tell us what to do. Those are the jobs of the observations that follow.

Two observations from the same evidence

What changed

The evidence stayed the same. The useful observation adds scope, interpretation, and consequence, then recommends an investigation that matches the certainty of the evidence. It does not pretend to know which dependency is responsible before anyone inspects the traces.

That is the practical value of the framework. A good observation turns measured evidence into something both an engineer and a decision-maker can use.

See what P95 and its cousins still hide once you're looking at tail latency.