Observability and optionality
Communicating tech in the language of business
(The podcast is pretty technical overall, but the first 12 minutes or so are accessible for anyone).
For me, this articulated the most important and recurring issue I’ve experienced throughout my tech career: the difficulty in finding the language to bridge the gap between the business and engineering domains.
It’s why I’m so passionate about the concept of optionality in software, and why I write about it so extensively.
Observability, Major’s core focus, is a fantastic example of the power and value of optionality in software. There are many definitions of ‘observability’ out there, but Majors simplifies it as being “the intersection of code, system, and users”.
Observability tools give the power to interrogate your system and how it behaves in production environments in ways you might not have been able to predict beforehand.
This last point is particularly important.
Whether it’s debugging something that went wrong, or understanding why customers suddenly changed their behaviour on the checkout page, we’re often responding to unexpected events. Rarely can we predict what information we’re going to care about tomorrow.
Tracking specific actions or metrics are well and good if we’re dealing with known unknowns, but often useless for unknown unknowns.
Because of this observability tools, like Honeycomb (of which Major is the CTO), are generally great investments. This is because the optionality they provide drives the value of the software ever higher, especially in highly uncertain domains such as startup product iteration, when deploying complex systems like microservices, or when using generative, non-deterministic AI tools.
Being able to easily, cheaply and powerfully interrogate information at that “intersection of code, system, and users” gives you a huge amount of flexibility, for a relatively cheap upfront cost. And with protocols like OpenTelemetry, you can even avoid the pain of vendor lock-in.
These tools make engineers’ jobs much simpler and easier. But they also make a company’s software much more valuable.
This is a language both engineers and business executives can understand.
I’m not sponsored or in any way affiliated with The Pragmatic Engineer or Honeycomb. I just think they’re both, in their own way, excellent.