Observability Engineering, 2nd Edition

Part VI. Observability Governance

So far, this book has been written for engineers: the people instrumenting code, running production services, and trying to understand what their software actually does in the real world. Parts I–V are written from the practitioner’s perspective, bottom up.

Part VI switches gears. We now write for technical leaders.

When we asked the software engineering community what was missing from observability guidance, we heard the same stories over and over: millions of dollars spent on tools nobody learned to use, CTOs who’d written observability off as irrelevant in a post-AI world, and organizations where nobody could agree on basic questions—what observability even is, what problems it’s supposed to solve, or who’s responsible for it. That’s a leadership problem, not a tooling problem.

Technical leadership comes in many forms—staff, principal, and distinguished engineers, as well as directors, vice presidents (VPs), senior VPs, CTOs, and similar roles. We don’t think this is solely the domain of executives. Technical contributors shape these decisions too, and we hope that comes through in these chapters.

The biggest problem we see right now is a widening gap: organizations are shipping code faster than ever, and simultaneously losing their grip on what that code actually does. Part VI is about closing that gap—through better decisions, better feedback loops, and leadership that takes both the technical and human sides of that problem seriously.