That feels more familiar than I'd care to admit - definitely been there, done that. I think what most fail to realize is that it eventually turns into a ball and chain, decreasing your mobility within the organization. So the consequences of running an org on tribal knowledge and Sarahs is far worse, and direct, than that it won't work very well with agents.

This might be the best article I’ve read in months. Thanks for sharing it!

Especially because it clearly showcases Garry Tan's (YC) grandeur delusions. Not only has he gone full state surveillance bullshit with Flock but also understands absolutely zero that he's vibe coding for 16 hours a day. And, shocker: it's pure slop!

thanks, glad you liked it! :)

Author here.

That sounds exhausting to say the least.

It’s very easy to turn into the Sarah - or the Brent if you prefer the Phoenix Project analogy. As exciting as it might initially be to be the go-to person, it’s also, as you so elegantly put it, “endless work, just enough authority to do current task, not enough respect/authority to solve the symptom”.

Best wishes! I hope you manage to turn it around.

Much appreciated! Thanks for the blog around ADR, I didn't know there was a full ecosystem for the approach and the AI tie in will help me sell the process

Because bug bounties are already dead.

have they though? i for one remember the "golden days" being much more about checking specific values for things you already know could happen than gathering telemetry to be able to ask questions you never would have even thought about asking at the time you set it up.

Out of curiosity, what relevance do you mean it would have for the specific topic I was writing about?

Author of the post here. I definitely agree with that assessment. Having multiple stacks monitor each other is a really good, albeit somewhat resource intensive, way to cover all of the *likely* cases. The cost of covering that last percent very quickly approaches the point of diminishing returns.

You start towards it in your post, but don't explicitly call it out: the central task is decreasing complexity.

A "dumb" heartbeat message, and a check for its absence, is reliable precisely because of its simplicity.

So if the question is "How do I monitor my complicated observability stack?" then the answer, to me, starts with "What is the simplest method of accomplishing the minimal version of my goals?"

Still my favorite console. 40 years later, it remains plugged in and used regularly.

logs, traces and profiling were all viable parts of a good monitoring stack even prior to the term observability being coined.

which i think is the point of the article as well. :)

The article mentions that the term “observability” was coined in 1960.

It very much is :-)