Observability for small teams

We end up explaining this on discovery calls often enough that it deserved writing down. Most advice about observability assumes a team that does not exist at your size. Here is the version that does not.

Cloud work rewards teams who automate early and punishes teams who click through consoles. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

What to keep

Monitoring tells you something broke, observability tells you why. This is the sort of thing that compounds, quietly, in both directions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Getting it slightly wrong is survivable. Ignoring it entirely is not.

What good looks like

Instrument the paths that lose money first. This is the sort of thing that compounds, quietly, in both directions. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

In practice

Operability is a feature, and it has to be built rather than bought. Three things worth confirming about observability before you move on:

• Someone can say what the current setup is without going to look
• Monitoring tells you something broke, observability tells you why — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.