The Minds Behind Observability – 7 People Redefining Software
Seven practitioners helped evolve monitoring into observability: high-cardinality telemetry, distributed tracing, exploratory debugging, standards, and production-oriented system design.
TL;DR
Seven practitioners helped evolve monitoring into observability: high-cardinality telemetry, distributed tracing, exploratory debugging, standards, and production-oriented system design. [1][2]
Why you should read it anyway
Monitoring asks known questions: is CPU high, is latency over a threshold, is a service down? Observability becomes essential when systems are too distributed and dynamic for teams to know every useful question in advance. Rich telemetry lets engineers investigate novel failure modes after they appear.
Imagine where Observability would be without them
Without these practitioners, metrics, logs, and tracing would still exist, but modern observability’s emphasis on high-cardinality context, exploratory querying, distributed traces, open telemetry standards, and debugging unknown unknowns would have spread more slowly.
Time Estimate of how many years we would be hindered without them for human progress
Editorial counterfactual estimate: 3–6 years. This is not a measured historical fact. It is an editorial estimate of how much slower the field might have matured without this cluster of people, institutions, practices, and tools.
The 7 people behind Observability
1. Charity Majors
Why they matter: became one of the strongest modern advocates for observability as a debugging practice for complex production systems. Through Honeycomb and public writing, she emphasized high-cardinality events, exploratory querying, and understanding unknown failure modes rather than relying only on predetermined dashboards.[1]
2. Cindy Sridharan
Why they matter: helped clarify observability for distributed systems through writing and talks on monitoring, tracing, resilience, and operability. Her work emphasized that operators need systems designed to reveal internal state under novel and unpredictable conditions.[2]
3. Liz Fong-Jones
Why they matter: connected SRE practice with modern observability, service-level objectives, tracing, and production debugging. Through engineering and education, she helped make observability an operational capability tied to reliability rather than a dashboard product category.[3]
4. Ben Sigelman
Why they matter: co-created Dapper-era distributed tracing work, founded LightStep, helped create OpenTracing, and later participated in the formation of OpenTelemetry. His work made distributed traces and vendor-neutral telemetry standards central to cloud-native observability.[4]
5. Peter Bourgon
Why they matter: worked extensively on distributed systems and production engineering and helped popularize practical thinking around metrics, instrumentation, and operability in cloud-native software. His public technical work connected application design with the signals operators need in production.[5]
6. Jaana Dogan
Why they matter: contributed to production engineering and observability at companies including Google and AWS and became a prominent educator on tracing, profiling, performance, and debugging distributed systems. Her work highlights observability as a software-design concern, not merely an operations add-on.[1]
7. Baron Schwartz
Why they matter: co-founded VividCortex and became an influential voice on database performance, monitoring, and observability. His work emphasized workload-centric diagnosis and the difficulty of understanding complex systems through coarse infrastructure metrics alone.[2]
How they each differ from one another
Majors championed high-cardinality exploratory debugging; Sridharan clarified observability and operability in distributed systems; Fong-Jones connected it to SRE and SLOs; Sigelman advanced distributed tracing and OpenTelemetry; Bourgon and Dogan emphasized production-oriented engineering; Schwartz brought workload-level observability to databases.
Final Take
Observability is not the number of dashboards a team owns. It is the degree to which a running system can explain itself when reality produces a question nobody predicted.
Works Cited
- 01
- 02OpenTelemetry — Project opentelemetry.io
- 03Honeycomb — Observability resources honeycomb.io
- 04
- 05Google Research — Dapper distributed tracing research.google
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead