There is a specific failure that shows up in marketing organisations of every size, and almost nobody has a name for it. The dashboards are green. The jobs are running. The weekly report shows tasks completed and campaigns active. And the business is producing nothing. Not less than it should. Nothing. The machinery is turning over perfectly while disconnected from the wheels.
Marketing strategist Jaivin Karnani has run into this pattern in enough environments to treat it as a category rather than an accident. The defining property is not that something broke loudly. It is that a green status and a dead pipeline look identical from the outside unless something measures the output. Once a team internalises that sentence, a surprising amount of “we are working on it” resolves into “nothing has shipped since March.”
Published: September 9, 2026. This article reflects Karnani’s operating pattern for diagnosing marketing systems that report health while producing no measurable output.
Why Activity Metrics Fail Quietly
Most marketing reporting is built on activity because activity is easy to instrument. Emails sent. Posts scheduled. Campaigns live. Jobs executed. Tickets closed. Every one of those numbers can be counted automatically, which is precisely why they became the default, and precisely why they are dangerous.
Activity metrics fail in one direction only: they over-report. A scheduled job that runs and produces zero output still counts as a job that ran. A campaign that is technically live but serving no impressions is still a live campaign. A content pipeline that executes end to end and writes zero articles has completed successfully by its own definition. There is no activity metric that under-reports a working system, which means every error they produce points the same way: toward false confidence.
The consequence is a reporting layer that is structurally incapable of delivering bad news. A leader reading it is not being lied to by anyone. They are reading an instrument that cannot show the failure mode they most need to see.
The Three Questions That Break the Illusion
Karnani’s diagnostic starts with three questions, asked in order. Each one is designed to be answerable with a specific artefact rather than an assurance.
What did this system produce, and when was the last one? Not “is it running.” Not “is it healthy.” What came out of it, and what is the timestamp on the most recent item. Compare that timestamp to today’s date. This single comparison catches the majority of silently dead pipelines, because a system that has produced nothing for eleven weeks will still happily report that it ran fifteen minutes ago.
Where does the output land, and can I look at it directly? A report about output is not output. The test is whether someone can open the actual thing: the published page, the sent message, the created record. Systems that produce reports about work rather than the work itself accumulate in organisations because they are never confronted with this question.
What would this look like if it were broken? This is the one that people find uncomfortable, and it is the most valuable. If the answer is “the same as it looks now,” the monitoring is decorative. A check that cannot fail is not a check. It is a reassurance mechanism, and it should be treated as a liability rather than an asset.
The Head-of-Line Problem
One mechanism deserves specific attention because it produces the most confusing version of this failure: a system where a small number of tasks consume all available capacity and everything behind them silently starves.
The shape is always the same. Work is processed in sequence. One or two items hang indefinitely rather than failing. Because they never fail, nothing raises an error. Because they never finish, nothing behind them starts. The queue looks busy. The system looks healthy. And ninety per cent of the work has not been touched in weeks.
It appears in marketing operations far outside of software. A content approval chain where two pieces sit unreviewed and everything queued behind them waits. An agency relationship where a single unresolved question blocks four workstreams. A launch calendar where one dependency slipped and the six things scheduled after it quietly rescheduled themselves into nowhere. In each case the organisation is not idle. It is fully occupied on a tiny fraction of what it believes it is doing.
The fixes are the same regardless of domain. Give every unit of work a deadline after which it fails rather than hangs, because a failure is visible and a hang is not. Process in an order that prevents starvation, so that the least-recently-touched work moves to the front rather than whatever happens to be first in the list. And measure the proportion of the queue that actually moved in a given period, not whether the queue was being processed.
Distinguish “It Failed” From “We Did Not Check”
Most reporting collapses verification into two states: pass and fail. Real systems need three. Something either succeeded, or failed, or could not be checked. Merging the third into the first is how organisations end up confidently wrong.
The distinction has teeth in ordinary marketing work. “The listing is correct” and “we could not access the listing to verify it” are completely different statements that get written into the same green cell in a status document. “The email sent” and “the send API returned a receipt” are different claims, and only one of them is evidence that a human received anything. A report that cannot express uncertainty will manufacture certainty instead.
The practical change is small: every verification writes one of three values, and “could not check” is escalated rather than rounded down. Teams resist this initially because it makes reports look worse. It does not make them worse. It makes them honest, and the difference between a report with visible unknowns and a report with hidden ones is the difference between a manageable problem and a surprise.
Rebuilding the Loop Around Output
The correction is not more monitoring. It is monitoring anchored to a different thing.
For every system that matters, define the unit of output it exists to produce, and instrument that unit rather than the process. A content system is measured in published pieces, with dates. A lead system is measured in qualified conversations, with names. An advertising system is measured in impressions actually served against the intended audience. Then set a staleness threshold — the interval past which the absence of output is itself an alert — and make the alert fire on silence rather than on error. Systems that fail loudly are the easy case. The expensive failures are the silent ones, and silence is only detectable if something is watching for it specifically.
One more discipline holds the whole thing together: the monitor must be able to report its own failure as distinct from the failure of the thing it monitors. A guard that goes quiet when it breaks is indistinguishable from a guard reporting all clear, and an organisation that cannot tell those apart has no monitoring at all.
Frequently Asked Questions
How is this different from ordinary KPI discipline?
KPI frameworks assume the reporting layer is accurate and argue about which numbers to prioritise. This is a prior question: whether the instruments are capable of showing failure at all. A perfectly chosen KPI fed by a metric that only over-reports will still mislead.
What is the fastest way to test whether a team has this problem?
Pick one system that is reported as healthy and ask for the last five things it produced, with dates, opened directly rather than described. The time it takes to get that answer, and whether the dates are recent, tells you almost everything.
Does this apply to small teams or only large ones?
It applies wherever work is delegated to a process rather than watched by a person, which includes a one-person business running automation. Scale changes how long the failure survives undetected, not whether it happens.
Is the answer to reduce automation?
No. The answer is to make automation accountable for output. Automation that is measured on what it produces is enormously valuable. Automation that is measured on whether it ran is a way of paying for the appearance of work.
Closing Note
The uncomfortable part of this diagnosis is that nobody is at fault in the usual sense. No one lied, no one was lazy, and the dashboards were not sabotaged. The organisation simply built instruments that could only tell it good news, and then believed them. That is an ordinary and forgivable mistake, and it is also the reason a business can spend a quarter fully occupied and produce almost nothing. The remedy is unglamorous and permanent: measure output, date it, alert on silence, keep a third state for what you could not verify, and be suspicious of any check that has never once failed.