You have a dashboard for everything except the thing you sell
Do a quick inventory with me. Open a new tab (mentally is fine) and count the dashboards your company looks at in a normal week.
There's the infrastructure one — CPU, RAM, disk, some tasteful green squares. There's the product analytics one — funnels, retention curves, that one chart everybody screenshots for the board deck. There's the revenue one — MRR ticking along, churn cohorts, the number that determines everyone's mood. Marketing has attribution. Support has ticket volume. If you're fancy, there's an uptime page with five nines of reassurance on it.
Now find the dashboard that answers this question: what did the code itself do today?
Not the servers the code runs on. Not the users clicking the product the code renders. Not the money the code generates. The code. Which functions worked hard today, which ones failed quietly, which ones haven't been called since March, which ones got slower this month. Where is that dashboard?
There isn't one. There has essentially never been one. And the truly weird part is that nobody finds this weird.
The observability industry watched the wrong thing
Here's an analogy that sounds unfair until you sit with it. Imagine a hospital with world-class monitoring of its buildings. Every room's temperature, every elevator's motor, every generator's fuel level — instrumented to the decimal, alarms everywhere. And no patient monitoring at all. No heart rates, no charts, no vitals. If a patient collapses in a hallway, the building sensors will faithfully report that the hallway is at a comfortable 21°C.
That is, more or less, the observability stack of 2026. The industry got genuinely great at watching machines: hosts, containers, pods, queues. It got great at watching requests: traces that follow one call on its journey through the system, like a nature documentary following one particular wildebeest. What it never built is the patient chart — the view where the durable unit is the function, the actual worker, with a name and a job and a medical history. Your APM can tell you that request #8f3a2c was slow on Tuesday. It cannot tell you that calculate_shipping — the employee — has been getting 2% slower every month for a year, or that legacy_export hasn't done a single day of work since 2024.
Machines are cattle; you replace them and nothing is lost. Functions are staff. The industry built livestock monitoring and called it observability.
But wait — don't engineering metrics cover this?
You might reasonably object that engineering already drowns in metrics: velocity, story points, commits, PR counts, DORA's deployment frequency and change-fail rate. Doesn't some combination of these add up to a code dashboard?
No, and it's worth being precise about why. Those metrics watch the production of code — how fast new material flows into the building. The gap I'm describing is about the behavior of the code already in the building. These are different objects. DORA's own research program, valuable as it is, measures the delivery pipeline: how quickly and safely changes move from laptop to production. It's a great instrument for the pipe. It says nothing about the water.
The SPACE framework researchers — Nicole Forsgren, Margaret-Anne Storey and colleagues, writing in ACM Queue — went further and warned that activity metrics are the most seductive and least meaningful measures in the whole field: no count of commits or PRs captures what's actually happening. They were writing about measuring developers. The point lands even harder for measuring code: a repository that received 400 commits last month tells you the building had 400 deliveries. It tells you nothing about which rooms are load-bearing, which are on fire, and which have been empty for years.
Adam Tornhill's Your Code as a Crime Scene showed how much can be recovered from version control alone — hotspots, coupling, knowledge maps mined from commit history. It's the closest thing the industry has to the missing chart, and even Tornhill's forensics, by construction, see where code changes, not what code does. A function can be untouched for three years and be the single most important worker in your company. Git will file it under "nothing happening here."
The alien auditor test
A thought experiment to make the gap concrete. An alien auditor lands in your office (bear with me) and asks three questions about the asset your company is built on:
- "Show me which parts of it worked hardest today."
- "Show me which parts failed today, and whether that's more or less than usual."
- "Show me which parts have done no work at all this quarter."
For your servers, you could answer all three in ninety seconds. For your marketing spend, all three. For your salespeople — yes, and there'd be a leaderboard. For your code? The honest answer is a long pause, then "we could probably reconstruct some of that from logs, given a week and a motivated engineer." The alien writes something down. It is not flattering.
The pattern here is old and human: we instrument what is easy to instrument, then slowly convince ourselves that what we instrumented is what matters. CPU was easy, so we watched CPU. Requests were easy, so we traced requests. The function — the actual atom of software work, the unit your engineers think in, the thing that has a name and a purpose and an author — fell through the gap between the infrastructure people and the analytics people, and stayed there for twenty years.
And there's a market reason nobody closed the gap: the buyers and the blind spot never met. Observability vendors sell to engineers, and engineers don't feel function-blind — each one holds a mental map of their own corner of the system, so a dashboard for "what does the code do" sounds redundant to the only people evaluating dashboards. Meanwhile the person who would benefit most — the owner, who holds no mental map at all — has never seen such a dashboard exist, and you can't demand a product you've never imagined. The hole persisted not because it was hard to fill, but because it sat exactly between two job descriptions, and holes between job descriptions are the most durable structures in any industry.
(The gap is closeable, for what it's worth. Watching every function as a durable, named worker with a history is exactly the layer CodeNSM adds under a stack like this — but the point of this post is the hole, not our plug for it.)
What the gap costs you
A missing dashboard sounds like an inconvenience. It's worse — it's a steering problem. Every resource-allocation decision your engineering org makes ("what do we refactor?", "where do we add tests?", "what do we rewrite?") is currently made using instruments that cannot see the thing being decided about. It's navigation by the dashboards you happen to have: the loudest recent incident, the ugliest-looking file, the module the most persuasive engineer dislikes. Attention flows to what's visible. The code's actual behavior — where the traffic is, where the failures cluster, where the decay is — remains off-instrument, so it loses every argument by default.
Later in this series we'll walk through the specific rooms this missing dashboard would have shown you: the dead code still drawing salary, the hot path nobody has mapped, the error rate everyone stopped noticing. Each one is a thing your current dashboards are structurally incapable of showing — not because they're bad, but because they're pointed at the machines, the users, and the money.
Everything, in other words, except the thing you sell.
Before you go — a short self-audit below. Score one point for every "no."