# Absence of Complaint Is Resignation, Not Satisfaction ## Claim When users of a service stop reporting problems, the most likely explanation is that they have lowered their expectations rather than that the service improved. <!-- atomicity: 1 idea ✓ --> ## Evidence **Source**: [[3. Resources/Readwise/Articles/How to Redesign a Broken Delivery Flow|How to redesign a broken delivery flow]] — a delivery diagnostic at a large enterprise platform team Satisfaction scores from internal clients came back in the **low single digits out of ten**, with specific complaints: *"I had no roadmap." "I don't understand why we are doing half of these steps." "We did not expect it to take so much time."* And then the observation that makes it a claim rather than an anecdote: > [!quote] > None of them were angry. The teams had simply stopped expecting better. The same engagement found one application had taken **more than a year** to move through the pipeline — and the team running that pipeline did not know. There was a feeling it was slow. Nobody had put a number on it, and nobody was escalating, because escalation had stopped seeming worth the effort. Anger is expensive to sustain, and people only pay that cost while they still believe improvement is possible. So a drop in complaints has two possible causes and they point in opposite directions: the problem was fixed, or the reporters gave up. **The two look identical from the receiving end**, which is what makes this dangerous rather than merely sad. ## Scope & conditions - Holds where the user has no exit — internal platform teams, mandated tooling, a project's only contribution path. Where exit is easy, they leave instead and you get churn rather than silence. - The diagnostic is to ask, not to wait: score satisfaction *and* ask for the reason behind the score. The reasons carried more information than the numbers in this case. - Does not mean silence is always bad news. A mature, genuinely working service also generates few complaints. The distinguishing question is whether anyone can *name* what improved. - The open-source translation is direct: **contributors who stopped filing issues** are the same signal, and read as satisfaction to the maintainers who could still fix it. ## Links - [[Commons & Community Governance MOC]] — what a commons looks like once its reporting paths have become costly enough to abandon - [[DevRel MOC]] — the signal DevRel most often misreads: quiet developers as satisfied developers - [[NAR and Charismatic Authority Critique MOC]] — the institutional silence that follows once speaking up has been made expensive - [[3. Resources/Permanent Notes/Procedural Burden Falls Hardest on Those With Least Standing]] — one mechanism that produces the silence: a reporting path demanding enough that good-faith reporters disqualify themselves - [[3. Resources/Permanent Notes/Institutional Response Speed Distinguishes Tolerated From Addressed Harm]] — the prior experience that teaches people not to bother reporting again - [[3. Resources/Permanent Notes/A Growing Categorized Issue Queue Measures Triage Capacity Not Just Backlog]] — contrasts on which direction the queue points: a growing queue means people still believe; a shrinking one may not mean what you hope - [[3. Resources/Permanent Notes/Friction Logging Is the DevRel Equivalent of Code Review]] — the active remedy: go find the friction rather than waiting for it to be reported - [[3. Resources/Permanent Notes/Adoption and Satisfaction Are Not Evidence That a Teaching Method Works]] — contrasts on direction: this note says quiet doesn't mean happy, that one says happy doesn't mean effective - [[3. Resources/Readwise/Articles/Silence Is Not Approval When Better Docs Create More Feedback - Uladzislava Lahun|Silence Is Not Approval (Lahun, Write the Docs Berlin 2026)]] — evidence-for: a two-writer docs team found that every new feedback instrument raised complaint volume (00:15:29) while ratings stayed flat, and reads a quiet channel as distance from the docs, not satisfaction with them (00:18:28). - [[3. Resources/MOCs/Events/Write the Docs Berlin 2026 MOC]] — evidence-for: Lahun's Write the Docs Berlin talk is indexed there with the two neighboring metrics talks. - [[3. Resources/MOCs/Documentation & Technical Writing MOC]] — applies-in: the docs discipline map, measurement cluster; the quiet-channel reading of docs feedback