Sooner or later someone on your team proposes "better observability". It arrives as a tooling request, with a vendor, a dashboard and an agent to install. You will not be the person who instruments the code, and you should not be. But the proposal contains decisions that are yours, and if you treat it as a purchasing question you will fund the wrong thing.
Underneath it is a different decision. Which questions must your team be able to answer about production without shipping new code first? Everything else, the vendor, the dashboards, the data volume, follows from that answer.
Learn the vocabulary before the vendors teach it to you
The words get used interchangeably in budget meetings, which is how a monitoring renewal gets sold as an observability investment. A good place to pin them down is Prathamesh Sonpatki's o11y wiki, an open-source A to Z glossary of observability terms he started in March 2023 while at Last9, aimed, in his own words, at "beginners like me who don't know a lot of observability and reliability".
Its definitions are plain. Observability is "the ability to understand the internal state of a system based on its external outputs". Monitoring is collecting and analysing data about a system from outside, based on what it outputs, and in practice is often restricted to metrics. Telemetry is the data itself, meaning logs, metrics and traces. Cardinality is the number of unique values an attribute can take, and the glossary notes that high cardinality can degrade dashboard performance, which is the first hint that cost and capability are tied together here.
Twenty minutes with that glossary will let you follow the conversation. It will not tell you what to decide. For that you need the distinction Charity Majors drew.
Monitoring answers the questions you wrote down
In her 2020 essay Observability is a many-splendored definition, Majors borrows the term from control theory. Can you understand any internal state the system gets itself into by asking questions from the outside alone? Applied to software, she defines it as the ability to ask any question of your systems, and to understand any user's experience, "without having to predict that question, behavior or experience in advance".
That last clause is the whole argument. Monitoring handles the questions you defined ahead of time, such as error rate, latency percentiles and queue depth. You set a threshold and you get paged when it is crossed. It is good at known problems. Observability is for the problems nobody predicted. Her example is deliberately awkward. Errors seen only by iOS users in three countries, only on one build of one microservice, only with a particular cache key. No dashboard was ever built for that question, and no dashboard could have been.
She then lists what a tool needs in order to answer such questions. One arbitrarily wide structured event per service per request, carrying the full context of that request. High cardinality, so a dimension like customer ID can hold millions of unique values. High dimensionality, so an event can carry hundreds of attributes. And raw, unaggregated data, because metrics discard the connective tissue at write time and you cannot get it back. The OpenTelemetry observability primer puts the same standard in operational terms. A system is adequately instrumented when developers do not need to add more instrumentation to troubleshoot an issue, because the information is already there.
The decisions that are yours
Once you hold that distinction, the manager's part of the proposal becomes visible. The question is no longer which product. It is four decisions.
Name the questions. Write down, with the team, five questions you must be able to answer about production within minutes. "Which customers hit the checkout slowdown between 14:02 and 14:20, and what did they have in common?" is one. If the honest answer today is "we would add logging and wait for it to happen again", that is a gap, and closing it is a funding decision you own rather than a ticket that lives at the bottom of the backlog.
Decide what cardinality you are paying for. This is where cost lives. In the GOTO book club conversation about their book on observability engineering, Majors, Liz Fong-Jones and George Miranda make the point that a high-cardinality field like customer ID is expensive or impossible in metrics-based systems and economically feasible in event-based ones. The cost models differ, and they differ on exactly the dimension your five questions need. Do not let a vendor's pricing page decide which questions your team can ask.
Protect the time to instrument. Instrumentation lives in the pull request that adds the feature, rather than in a "later" ticket. If your team's definition of done does not include emitting the context needed to debug the change, you have decided, quietly, that the first incident will be investigated blind. Say so out loud or change the definition.
Refuse dashboards as the deliverable. A dashboard is a question somebody already thought of. Ask instead for a demonstration. Pick an incident from the last quarter and have the team show you, in the tool, how they would narrow it from "errors are up" to the specific population affected. If they cannot, you have not bought observability, whatever the invoice says.
Questions to ask in the next design review
You do not need to know how spans are propagated. You do need to ask, every time a new service appears, what identifier travels with a request through this service, and whether you could find one customer's path through it tomorrow. Which attributes does it emit, and are any of them high cardinality by design? If the on-call engineer sees a latency spike here, what is the first query they run, and does the data exist to run it?
Those questions take two minutes each and they are the kind of technical judgment that survives your coding depth fading. Majors' standard is a useful test of your own understanding as well. If you cannot describe a question the team could not answer last month and can answer now, the investment has not landed yet.
Where this sits in the standard
Reliability, incident response and operational ownership is competency DE-3 in the EMA Competency Framework, in the Delivery & Execution domain. The DE-3 unit of the Body of Knowledge covers what a manager owns in production, and TJ-4 covers staying credible enough to ask the questions above without doing the instrumenting yourself.
In EMA-I it appears as a situation where a team proposes an observability investment and you decide what to fund, what to require and what to refuse. See what EMA-I covers.