SEO Is the Cleanup Crew for Organisational Dysfunction  🔗 **Source:** [SEO Is the Cleanup Crew for Organisational Dysfunction](https://www.jonoalderson.com/conjecture/organisational-dysfunction/) > [!note]+ Document Notes > tags: [organisational-design, seo, capability-gaps, institutional-knowledge, incentives, devrel, platform-teams, measurement] > author: Jono Alderson > source: jonoalderson.com > reference: https://www.jonoalderson.com/conjecture/organisational-dysfunction/ > date created: 2026-08-24 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ SEO is the Cleanup Crew for Organisational Dysfunction > <!-- deep-read:sections start --> ## 🧭 Table of Contents 1. Summary 2. Main Content 3. References 4. Paraphrase 5. Newsletter 6. Action Items 7. Hypotheses 8. Methodology 9. Questions 10. Future Research 11. Implications 12. Learning Styles Assessment 13. Accessibility Assessment 14. DEIB Assessment 15. Logical Validity 16. DARVO Analysis 17. Conclusion 18. Refactor Appendix 19. Template Library ## 🔗 References (in-page) - "SEO is no longer enough" — Alderson's prior piece, linked as the argument this extends - "SEO vs GEO is the wrong question" — linked; the framing he rejects - "Clicks don't count" — linked; his argument that rankings and clicks are outputs of a larger system - Filed under `/conjecture/` — the author's own signal that this is an argument in progress, not a settled claim ## 📝 Summary **What happened.** Jono Alderson argues that SEO functions as an organisation's cleanup crew: it finds failures across engineering, content, brand, product, PR, and analytics because its work spans all of them, and then absorbs those failures without holding the authority to prevent them. The piece names the resulting trap, traces its incentive structure, and prescribes a different definition of success — designing failures out upstream, handing ownership to the team that controls the system, and measuring what stops recurring rather than what got closed. **Why it matters.** The argument is about SEO and applies to every horizontal function that sees across a system it cannot change: DevRel, documentation, accessibility, QA, design systems, platform teams, security. Each has the same structural position — broad visibility, narrow authority — and each accumulates the same pathology, where competence at absorbing dysfunction becomes the reason the dysfunction survives. **Stakeholders.** Horizontal function leads and their managers; executives reading activity dashboards as health; platform and product teams receiving handoffs; consultancies whose revenue model depends on recurring audits; anyone who has become load-bearing for a process they don't own. **Risks.** The prescription asks a team to reduce its own visible output, which cuts against how that team is funded, staffed, and promoted. Alderson names this tension but doesn't resolve it — and the reader with the least authority is the one most exposed if they follow the advice unilaterally. **Bottom line.** A team rewarded for catching failures it has no authority to prevent will keep catching them, because its competence at cleanup is what lets the organisation keep producing the mess — and the only exit is to move the correction upstream into a default, a test, or an owner, then measure which categories of work stop coming back. ## 📖 Main Content ### 🗒️ Notes **The observation.** SEO finds the breakage — a redesign that doubles page weight, product pages carrying three teams' worth of contradictory messaging, analytics that stopped measuring the thing presented to the board, six months of unread customer complaints on Reddit. Alderson's explanation is positional: SEO works across technology, content, brand, product, PR, and analytics, which makes it "a meta-discipline, not a tidy marketing channel in a tidy box on the org chart." **The inheritance.** The list is precise about *why* work lands here: performance "because nobody owns it," structured data "because engineering finds it boring," product copy "because apparently somebody has to explain what the thing does." Each is a different mechanism of orphaning — unassigned, unappealing, unclaimed. **The trap, stated.** This is the thesis sentence and the piece's center of gravity. > [!quote] > There is satisfaction in walking into a mess and leaving it less broken. But an organisation with > a reliable cleanup crew has less reason to stop making the mess. That’s the trap: a team rewarded > for catching failures it has no authority to prevent. **Why SEO specifically.** He credits nosiness and, more concretely, signal access — crawl data, demand, competitors, reviews, citations, forums, performance, analytics. The framing of what each team sees is the sharpest passage in this section: engineering sees the platform, brand sees the message, product sees the problem it solves, support sees the customer in front of them, and "SEO sees some of the joins and what leaks through them." He's careful to disclaim uniqueness — good researchers, analysts, and product teams also work across boundaries — which strengthens rather than weakens the argument by making it a structural claim rather than a professional one. **Signals as evidence, not verdicts.** Search demand exposes gaps between market language and the company's internal model; reviews show where brand promise diverged from experience; crawl data reveals engineering debt; content gaps indicate missing expertise or weak ownership. He then constrains the inference twice — "These are clues, not diagnoses," and a line worth keeping: > [!quote] > A dashboard is not an oracle simply because it contains several decimals. One angry Reddit post > proves very little. Several independent signals pointing at the same weakness deserve attention. **Capability gaps disguised as queues.** The mechanism by which organisations hide structural weakness is the most transferable idea in the piece. > [!quote] > Organisations are good at disguising these weaknesses as queues of work. Twenty bad product > descriptions become twenty copy tickets. Ten slow templates become ten performance tickets. > Dashboards turn green; the underlying problem remains gainfully employed. The audit's job, correspondingly, is to show which failures share a cause, who absorbs the consequences, and what the organisation cannot do without specialist intervention — "otherwise it is just a more expensive backlog." **The cost of indispensability.** Knowing which template breaks canonical tags, which dashboard is lying, which release process bypasses checks, and who in engineering might fix something "before 2050" is useful knowledge and "also a fairly damning description of the system." The team becomes "a manual exception layer, supported by spreadsheets, scripts and undocumented rituals," with costs scattered across audits, meetings, and escalations such that "each intervention looks tolerable, so nobody examines the total." He extends this to explain why a large SEO team can coexist with long-unsolved problems: more people means more capacity to absorb dysfunction, the way accumulated advantage lets zombie companies look healthy while capability decays. **The incentive inversion.** Stated plainly, and it's the reason the trap is stable: > [!quote] > Rescue a disastrous migration, and everybody knows about it. Make future migrations uneventful > and, ideally, nobody notices. More involvement can look like influence when it really shows that > the business cannot operate without supervision. **Designing the failure out.** The escalation rule is concrete: fixing internal links after the first migration is reasonable; "by the third time, continuing to fix them is an admission that nobody intends to fix the migration process." Corrections belong upstream — metadata in templates, performance requirements in the release process, contradictory product information in an owned source of truth. He explicitly rejects governance as the answer, noting large organisations already produce process "designed to demonstrate that the correct boxes were ticked shortly before something went wrong," and instead names four places a correction can live where it's harder to ignore: a default, a test, a source of truth, an owner with authority. **Handoff, and its discomfort.** SEO can identify the failure mode and specify what good looks like, but permanent ownership belongs to the team controlling the platform or product — "otherwise the bottleneck has merely moved." He's honest about the cost: the receiving team may have worse judgement, less urgency, "a distressing appetite for relearning expensive lessons," and things will regress. That's still healthier than routing every decision through approval. The test is memorable: > [!quote] > If it collapses when the SEO lead takes six months off, it was dependency in a nicer outfit. **Measure what stops recurring.** Activity metrics — audits completed, tickets closed, recommendations implemented — "can also describe an organisation standing perfectly still." As capability improves, whole categories of intervention should vanish: performance audits become rare because tests are in delivery, metadata reviews disappear because templates behave, teams stop asking questions because answers no longer live in someone's head. He then names the awkward part directly — a team measured on tickets needs tickets, a consultancy paid for audits needs things to audit — and concedes the balance: measure both, because commercial outcomes still matter and not every intervention should disappear. **The close.** SEO "does not need a grander title. It needs a better definition of success." Connect signals other teams see separately, expose recurring causes, put the correction where it can be owned, then step back. "We should still fix the broken thing. But the point is to stop being needed for the same class of failure twice." ## 📚 References - Alderson, "SEO is no longer enough" and "SEO vs GEO is the wrong question" — the surrounding argument on his site - Alderson, "Clicks don't count" — the measurement critique this piece builds on - Westrum's typology of organisational cultures — the generative/bureaucratic/pathological framing this describes without citing - *Accelerate* (Forsgren, Humble, Kim) — the empirical case for measuring outcomes over activity, and for building quality into delivery - Conway's law literature — why "SEO sees the joins" is a structural prediction rather than an observation about SEO - Blame-aware incident review practice (Allspaw and others) — the counterpart discipline for treating recurrence as a systems property ## 🗣️ Paraphrase When something breaks on a website, SEO usually finds it — because SEO's work crosses every department that can affect whether people find, understand, or trust a business. That makes it a meta-discipline rather than a channel, and it means the work nobody owns drifts there by default. Which produces a specific trap. It feels good to clean up a mess. But an organisation that has a reliable cleanup crew has less reason to stop making messes. The team gets rewarded for catching failures it has no power to prevent. SEO ends up in this position because of what lands on its desk — crawl data, demand, reviews, forums, performance, analytics. Every other team sees its own system; SEO sees the joins between them and what leaks through. Those signals are clues, not diagnoses, and one angry Reddit post proves nothing. Several independent signals pointing at the same weakness are worth taking seriously. The deeper pattern is that organisations hide missing capabilities inside queues of work. Twenty bad product descriptions become twenty copy tickets. The dashboard goes green and the actual problem keeps its job. Then indispensability sets in. Knowing which template breaks and which dashboard lies is useful, and it's also a damning description of the system. The team becomes a manual exception layer. Every individual intervention looks affordable, so nobody adds them up. The incentives make it worse. Rescue a disaster and you're visible. Prevent future disasters and nobody notices. Being in every meeting looks like influence when it actually means the business can't operate unsupervised. The way out is upstream. Put metadata in templates, performance in the release process, product truth in an owned source. Not more governance — a default, a test, a source of truth, an owner with authority. And then hand it over, even though the receiving team will be slower and will regress, because a capability that dies when one person takes leave was never a capability. Finally, change what you count. Activity metrics can describe a company standing still. The real measure is which categories of work stop coming back — while admitting the uncomfortable part, that a team paid for tickets needs tickets. ## 📰 Newsletter **The cleanup crew problem** Jono Alderson has written the best description I've read of a trap that isn't really about SEO at all: *"a team rewarded for catching failures it has no authority to prevent."* His case is that SEO finds the organisation's breakage because its work crosses engineering, content, brand, product, PR, and analytics. Everyone else sees their own system. SEO "sees some of the joins and what leaks through them." So it inherits performance because nobody owns it, structured data because engineering finds it boring, and product copy because someone has to explain what the thing does. Swap in DevRel, docs, accessibility, or QA and every sentence still works. The mechanism he names is the part worth stealing: organisations disguise missing capabilities as queues of work. *"Twenty bad product descriptions become twenty copy tickets. Ten slow templates become ten performance tickets. Dashboards turn green; the underlying problem remains gainfully employed."* Then the incentive that keeps it stable — rescue a disastrous migration and everyone knows; make future migrations uneventful and nobody notices. Being in every meeting reads as influence when it actually means the business can't run unsupervised. His prescription isn't more governance. It's putting the correction somewhere harder to ignore: a default, a test, a source of truth, an owner with authority. Then handing it over and accepting that the receiving team will be worse at it for a while. His test for whether a handoff was real: *"If it collapses when the SEO lead takes six months off, it was dependency in a nicer outfit."* And change the scoreboard. Count what stops recurring, not what got closed — while being honest that a team measured on tickets needs tickets, and a consultancy paid for audits needs things to audit. Filed under `/conjecture/` on his site, which is the right label. It's an argument, not a methodology. It's also uncomfortably accurate. ## ✅ Action Items **DevRel** - Run the recurrence audit: list the last two quarters of work and mark which items are the same class of failure repeating. That ratio is the real maturity metric, and almost nobody has it. - Reframe reporting around categories retired, not content shipped or questions answered. Add one line to the monthly: "what stopped coming back." - Identify where DevRel is a manual exception layer — the undocumented rituals, the person who knows which release process skips the checks — and write down what would have to exist for that knowledge to stop being personal. **OSPO** - This is the structural diagnosis for why open source program offices burn out: broad visibility, narrow authority, and the same failures recurring across teams that don't own the fix. - Apply the four correction sites — default, test, source of truth, owner — to contribution requirements rather than publishing more policy. **Community** - Community teams absorb the same class of dysfunction (surfacing problems they can't fix) and are measured the same way (activity). The "capability gap disguised as a queue" framing is directly usable in a staffing conversation. **WordPress subteams** - **Core** — recurring classes of bug and review friction are capability gaps, not ticket volume. Which categories have actually retired in the last year? - **Core Performance** — the canonical example in the article. Performance requirements belong in the release process, not in per-project negotiation. This is the team best positioned to test the thesis. - **Documentation** — docs is the archetypal cleanup crew: it absorbs unclear product decisions as explanatory burden. Every "we should document that better" is a candidate capability gap upstream. - **Accessibility** — the clearest case in the project. The team finds failures continuously and holds no authority to prevent them, and the Accessibility Lab plugin work is an attempt to move the correction into tooling — exactly the prescription here. - **Training** — "answers no longer live in somebody's head" is a curriculum goal. Also: teaching a workaround durably is how a workaround becomes permanent. - **Design** — design systems exist to make correct defaults cheaper than incorrect ones, which is this argument implemented. - **Meta** — instrumentation for recurrence (same class of issue reopening) would make this measurable rather than anecdotal. - **Plugins / Themes** — review teams absorb the ecosystem's recurring defects; the automated-check question is whether the correction lives in a test or in a reviewer's memory. - **Support** — the article names support explicitly as holding knowledge that never reaches product. That path is a concrete, fixable capability gap. - **Polyglots / Photos / TV / Openverse / CLI / Tide / Mobile / Playground / Core AI** — not applicable to this source directly, though the horizontal-function pattern applies to any of them operating across teams. - **The WPOCC** — a collective taking stewardship inherits exactly this risk: becoming the reliable cleanup crew for gaps nobody else will own. Worth deciding deliberately which gaps it will absorb and which it will refuse. **FAIR** - Not applicable to this source. No federation or distribution dimension appears. ## 🧪 Hypotheses 1. Horizontal functions with broad visibility and narrow authority show higher burnout and turnover than functions whose scope and authority match. 2. The count of *distinct recurring failure classes* predicts organisational health better than total ticket volume. 3. Teams that successfully hand off a capability experience a temporary measurable regression followed by lower total intervention cost within a year. 4. Organisations that reward visible rescue produce more rescues; prevention work is underrepresented in promotion cases relative to its value. 5. Capability gaps presented as queues persist longer than the same gaps named as missing ownership, controlling for cost to fix. 6. A function's headcount growth without a decline in recurring failure classes indicates absorbed dysfunction rather than expanded capability. ## 📊 Methodology Argument essay from practitioner experience. No study, no data, no cases with names or numbers. The author files it under `/conjecture/` on his own site, which is an accurate and unusually honest self-classification — he is not presenting this as validated. The evidence is pattern recognition across an unstated number of client organisations, presented as recognisable archetypes rather than instances. That's the standard form for this genre, and its persuasive force comes from reader recognition rather than from measurement: the argument works if you have seen it, and offers you no way to check it if you haven't. What's absent and would be testable: recurrence rates before and after a handoff, the total cost of the manual exception layer he describes, and any case where the prescription was followed and either worked or didn't. The claim that categories of intervention should disappear as capability improves is falsifiable and unfalsified here. One methodological strength: the argument is structural, and he explicitly disclaims that the visibility advantage is unique to SEO. That makes it a claim about organisational position rather than about a profession, which is both broader and easier to test. ## ❓ Questions - When *should* a horizontal function stay permanently involved? He concedes "not every intervention can or should disappear" and never says which ones. - What does a team do when it holds the diagnosis and no authority, and leadership is uninterested? The prescription assumes a receptive organisation. - How do you fund a function whose success reduces its visible output? He names the incentive problem and stops there. - Where's the case study? The escalation rule (third migration) implies he has watched this specific pattern; the piece would be stronger and more falsifiable with one instance. - What distinguishes a healthy exception layer — genuine specialist judgement — from an unhealthy one? "Some dependence on those people is inevitable" needs a boundary. - Does handing off to a team with worse judgement ever produce unrecoverable damage rather than survivable regression? - Who audits the auditor? The consultancy incentive he names applies to his own profession, and he raises it without turning it on himself. ## 🔮 Future Research - Instrument recurrence: build a taxonomy of failure classes and measure retirement rates over time, which would turn this argument into a metric. - Study handoff outcomes longitudinally — regression depth, recovery time, and whether the capability survives a leadership change. - Compare functions where visibility and authority are matched against those where they aren't, on turnover and on problem persistence. - Examine promotion and compensation data for evidence that prevention work is systematically undervalued relative to rescue. - Test whether naming a capability gap explicitly (versus filing tickets) changes time-to-resolution. ## 💡 Implications **Practice.** Before closing a ticket, ask what class it belongs to and whether that class has appeared before. The third instance is the signal to stop fixing and start relocating. **Policy.** Activity metrics — tickets closed, audits delivered, pages shipped — can describe an organisation standing still. Any function reported this way needs a second number: which categories of work stopped recurring. **Security.** The same structure produces security debt. A security team that catches issues in review without authority over the release process is a cleanup crew, and the fix is identical — move the correction into a default, a test, or an owner. **Education.** Teaching people to execute a workaround durably is how a workaround becomes permanent infrastructure. Curriculum should distinguish "how to work around this" from "why this exists and who should fix it." **Funding.** The unresolved tension: a team, consultancy, or program funded on visible intervention has a structural reason not to eliminate the need for intervention. Any org serious about this has to change how the function is funded, not just how it behaves. ## 🧠 Learning Styles Assessment - **Visual** — Weak. No diagrams. An argument about where corrections should live — template, release process, source of truth, owner — is asking for one, and the absence is the piece's clearest presentational gap. - **Aural** — Not applicable to this source. Text only, though the prose has a strong spoken cadence and would read aloud well. - **Verbal** — Strong. This is the piece's whole channel: precise, dryly funny, and built on memorable formulations ("dependency in a nicer outfit," "remains gainfully employed"). - **Kinesthetic** — Moderate. The three-migrations escalation rule and the six-months-off test are directly applicable; there's no exercise or template. - **Logical** — Strong. Clean progression from observation to mechanism to incentive to prescription to measurement, with each section resolving the problem the previous one raised. - **Social** — Weak. No quotes from others, no named cases, no dialogue. Written as one practitioner's argument, addressed to peers. - **Solitary** — Strong. 1,629 words, self-contained, one sitting, no prerequisites beyond having worked in an organisation. - **Naturalistic** — Not applicable to this source. Metaphors are institutional (cleanup crew, zombie companies, religious ceremony) rather than natural-world. **Reading level.** Approximately grade 12. Long compound sentences, subordinate clauses, domain-specific vocabulary (canonical tags, structured data, internal linking, performance budgets), and heavy reliance on British understatement and irony, which is a comprehension load in itself — "a minor religious ceremony" and "before 2050" both require reading past the literal. Fluent English readers with organisational experience will find it easy; the ironic register makes it harder for non-native readers than the vocabulary alone suggests. ## 📊 Accessibility Assessment Mapped to WCAG 2.2 AA: 1. **Perceivable — text alternatives (1.1.1).** Text-dominant with minimal imagery in the extracted content. Low exposure; nothing to fail on the available evidence. 2. **Perceivable — structure (1.3.1).** Strong, descriptive headings that carry the argument independently ("Why SEO keeps finding the bodies," "The cost of becoming indispensable," "Measure what stops recurring"). A reader navigating by heading gets the whole thesis. Exemplary. 3. **Perceivable — contrast (1.4.3).** Not verifiable from extracted content. 4. **Operable — link purpose (2.4.4).** In-text links use descriptive phrases ("SEO is no longer enough," "clicks don't count") rather than bare URLs or "click here." Passes. 5. **Understandable — reading level (3.1.5).** Grade 12 with ironic register. WCAG's AAA guidance suggests supplementary plain-language material for content above lower-secondary level; not required at AA, but the irony compounds the difficulty in a way raw readability scores miss. 6. **Understandable — jargon (3.1.3).** Canonical tags, structured data, internal linking, and performance budgets appear unglossed. Appropriate for the audience; a barrier for the cross-functional readers the argument would most benefit. 7. **Robust — emphasis semantics (4.1.2).** Italic emphasis appears on key terms ("meta-discipline," "nosy," "us"). Needs `<em>` rather than `<i>` for the stress to survive to assistive tech — these carry argumentative weight, not decoration. ## 🌍 DEIB Assessment **Cultural breadth.** Narrow by construction. The assumed context is a large Western corporate organisation with Jira, agencies, board presentations, and departmental silos. British idiom is heavy — understatement, dry irony, "a minor religious ceremony," "gainfully employed" as a joke about a problem. Readers outside that idiom will lose some of the argument's texture, and the humour does real persuasive work here. **Inclusive language.** No exclusionary language. Notably, no individual or role is blamed — the diagnosis is consistently structural. Engineering "finds it boring" is the closest to a dig, and it's mild and self-evidently affectionate. **Neurodiversity support.** Mixed. Structurally strong: clear headings, short paragraphs, one idea per section, and a linear argument. Working against that: the ironic register requires inferring intent from tone, which is a real access cost for some readers, and the piece never states its claims twice or summarises. There's no TL;DR. The article's substance is also relevant here and unremarked by it: undocumented rituals, knowledge living in someone's head, and processes requiring "somebody remembering forty-seven fragile checks" are disproportionately taxing for people with working-memory differences. Making corrections explicit — a default, a test, a source of truth — is an accessibility improvement in organisational form. **Representation.** No individuals quoted or named beyond the author. Compared with the community-sourced articles in this batch, which name dozens of practitioners, this is a single authoritative voice. That's the genre convention for an argument essay and it does mean the claims rest entirely on one person's credibility. **Psychological safety.** The subject matter, obliquely. A piece arguing that a team should reduce its own visible indispensability is asking readers to act against their apparent self-interest — which is only safe in an organisation that won't punish them for it. Alderson names the incentive problem honestly and doesn't pretend the risk away, but he also doesn't address who can afford to follow the advice. Someone with tenure and standing can hand work back; someone junior or on a renewable contract cannot. ## ✅ Logical Validity **Strong reasoning.** - The central mechanism is genuinely explanatory rather than descriptive: it says *why* the pattern is stable (competent absorption removes the pressure to fix the source), which makes it a causal claim and not just an observation. - Disclaiming SEO's uniqueness — "That view is not unique to SEO" — strengthens the argument by making it structural. He gives up a professional-flattery move in exchange for generality, which is the right trade and an unusual one. - The epistemics on signals are careful and consistent: clues not diagnoses, one post proves little, convergent independent signals deserve attention. He applies the same standard to his own field's data that he asks others to apply. - He names the objection to his own prescription (a team measured on tickets needs tickets; a consultancy paid for audits needs audits) rather than leaving it for a critic, and concedes the balance ("we should measure both") instead of overclaiming. - Rejecting governance as the answer is well-argued and non-obvious — process that documents compliance is distinguished from correction that changes defaults. **Fallacies.** - **Unfalsifiable framing risk, "cost of becoming indispensable."** Both high involvement and low involvement can be read as evidence of the thesis — deep involvement means dysfunction, and successful prevention is invisible by design. Without a stated way to distinguish healthy specialist dependence from unhealthy absorption, the claim resists disconfirmation. He gestures at the boundary ("some dependence on those people is inevitable") and never draws it. *Fix:* specify what a healthy exception layer looks like. - **Anecdotal foundation.** Every archetype is asserted from unstated experience. The three-migration rule implies specific observation and cites none. *Fix:* one worked case would convert the strongest claims from recognisable to demonstrated. The `/conjecture/` filing partly discharges this. - **Loose analogy, "zombie companies."** Accumulated advantage masking capability decay is suggestive rather than argued; the economic term is doing rhetorical work its actual definition doesn't support. *Fix:* drop it or make the parallel explicit. - **Suppressed difficulty in the handoff prescription.** "Things will regress. That is still healthier" asserts the tradeoff without bounding it. Some regressions are recoverable and some cost customers or safety, and the piece treats them as one category. *Fix:* condition the advice on failure severity. - **Survivorship in the prescription.** Organisations that successfully relocated a capability are invisible here alongside those that tried and failed, so the success rate of the advice is unknown. *Fix:* acknowledge that handoff has a failure mode of its own. **Tone of voice.** Dry, precise, British-ironic, and confident without being strident. The humour is load-bearing — "a minor religious ceremony," "before 2050," "an SEO workaround with grander stationery," "remains gainfully employed" — and it functions to make an uncomfortable self-implicating argument tolerable. First person plural throughout ("us," "we"), which is doing something specific: he places himself inside the profession being critiqued, so the piece reads as self-examination rather than accusation. That choice is why the argument lands rather than offends. ## 🛡️ DARVO Analysis **Deny** — None present. No accusation is being answered, and the author accepts rather than deflects responsibility on behalf of his own profession. **Attack** — None. The obvious available move — blaming engineering, leadership, or product for creating the messes SEO cleans up — is declined. Failures are attributed to structure ("nobody owns it") rather than to people or teams. The one mild characterisation, engineering finding structured data boring, is offered as explanation rather than indictment. **Reverse Victim and Offender** — None present, and notably inverted. The piece could easily have positioned SEO as the wronged party heroically absorbing others' failures — the setup supports it, and much of the genre does exactly that. Instead the argument turns on SEO's own complicity: the cleanup crew's competence is what allows the mess to continue, and the career incentives that make rescue attractive are named as a problem the author's own profession has. Not applicable to this source in substance, and worth filing as a positive contrast case: practitioner criticism that assigns the fixable share of the problem to the author's own side. ## 🎯 Conclusion **Bottom line.** A horizontal function that sees across a system it cannot change will accumulate the failures nobody owns, and its competence at absorbing them removes the pressure to fix their source — so the exit isn't more authority or a better title, it's relocating the correction into a default, a test, a source of truth, or an owner, and then measuring which categories of work stop coming back. **Next steps.** 1. Classify the last two quarters of work by failure class and count repeats. That number is the diagnosis. 2. For any class at three or more instances, stop fixing instances and specify where the correction belongs upstream. 3. Add "categories retired" alongside activity metrics in reporting, and expect the first version to look bad. 4. Apply the six-months-off test to anything recently handed over. 5. Decide deliberately which gaps to absorb and which to refuse — the piece's advice is unsafe to follow unilaterally without standing. ## 🧱 Refactor Appendix ### Literature Split Pad #### The cleanup crew trap > [!quote] ID:rw_jono_trap > There is satisfaction in walking into a mess and leaving it less broken. But an organisation with > a reliable cleanup crew has less reason to stop making the mess. That’s the trap: a team rewarded > for catching failures it has no authority to prevent. *Where:* Opening section, after the list of inherited responsibilities. *Why:* The thesis. Names a stable equilibrium in which competence at remediation is the mechanism sustaining the problem, and locates the defect in the mismatch between visibility and authority. #### Capability gaps disguised as queues > [!quote] ID:rw_jono_queues > Organisations are good at disguising these weaknesses as queues of work. Twenty bad product > descriptions become twenty copy tickets. Ten slow templates become ten performance tickets. > Dashboards turn green; the underlying problem remains gainfully employed. *Where:* "Capability gaps" section. *Why:* The concrete mechanism by which structural weakness becomes invisible — decomposition into tickets converts one missing capability into many closeable items, and closing them measures throughput while the cause persists. #### The incentive inversion > [!quote] ID:rw_jono_incentive > Rescue a disastrous migration, and everybody knows about it. Make future migrations uneventful > and, ideally, nobody notices. More involvement can look like influence when it really shows that > the business cannot operate without supervision. *Where:* "The cost of becoming indispensable." *Why:* Explains why the trap survives contact with rational actors — prevention is invisible by construction, so the reward structure selects for rescue, and the appearance of influence is evidence of institutional weakness rather than personal power. #### The handoff test > [!quote] ID:rw_jono_handoff > If it collapses when the SEO lead takes six months off, it was dependency in a nicer outfit. *Where:* "Designing the failure out," on why handoff matters. *Why:* A single falsifiable test for whether a capability was actually transferred or merely re-labelled — absence of the individual, not the occurrence of a handoff meeting, is the evidence. #### Signals as clues, not verdicts > [!quote] ID:rw_jono_oracle > A dashboard is not an oracle simply because it contains several decimals. One angry Reddit post > proves very little. Several independent signals pointing at the same weakness deserve attention. *Where:* After the list of what search, reviews, and crawl data expose. *Why:* Sets the evidentiary standard the rest of the argument depends on — convergence across independent signals, rather than precision within one, is what licenses a structural conclusion. ### Atomic Split Pad #### Reliable remediation removes the pressure to fix the cause A team that competently absorbs a recurring failure supplies the organisation with a reason not to prevent it, so remediation capacity and structural improvement are in tension rather than in sequence. <!-- atomicity: 1 idea ✓ --> #### Decomposing a missing capability into tickets makes it invisible Splitting one structural gap into many individually closeable work items converts an unowned problem into measurable throughput, so the metrics improve while the cause persists untouched. <!-- atomicity: 1 idea ✓ --> #### Prevention is structurally underrewarded because success is unobservable Averted failures generate no evidence of themselves, so any incentive system built on visible outcomes will overpay for rescue and underpay for the work that makes rescue unnecessary. <!-- atomicity: 1 idea ✓ --> #### A capability that depends on a person's presence was never transferred Whether a handoff succeeded is testable only by the receiving team's performance in the absent expert's absence, which makes departure — not the transfer meeting — the evidence. <!-- atomicity: 1 idea ✓ --> #### Visibility without authority converts a function into an absorption layer When a team can observe failures across a system it holds no power to change, its output becomes compensation for the defect rather than correction of it, and its headcount measures dysfunction absorbed rather than capability added. <!-- atomicity: 1 idea ✓ --> #### Maturity shows as categories of work disappearing Because improving capability retires whole classes of intervention rather than accelerating them, a stable or growing volume of the same remedial category indicates absorbed dysfunction regardless of how efficiently it is processed. <!-- atomicity: 1 idea ✓ --> ### Fleeting Queue - The unresolved question: how do you fund a function whose success reduces its visible output? He names it and stops. That's the actual hard problem. - "A minor religious ceremony" for a three-team, two-agency content update — the funniest accurate description of enterprise CMS governance I've read. - Who can afford to take this advice? Handing work back requires standing. Junior and contract staff can't. - Cross-batch: this is the same shape as Common Room's doorway argument and The Admin Bar's Cloudflare Zero Trust answer — relocate the correction rather than improving the workaround. - Accessibility Lab plugin as WordPress's instance of "move the correction into tooling." - Where's the boundary between healthy specialist dependence and an unhealthy exception layer? The piece needs it and doesn't supply it. - Filed under `/conjecture/` — worth stealing as a publishing convention. An honest epistemic label on a URL. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/SEO Is the Cleanup Crew for Organisational Dysfunction.md|SEO Is the Cleanup Crew for Organisational Dysfunction by jonoalderson.com]] ## Highlights - There is satisfaction in walking into a mess and leaving it less broken. But an organisation with a reliable cleanup crew has less reason to stop making the mess. That’s the trap: a team rewarded for catching failures it has no authority to prevent. SEO keeps ending up here because of what it can see. ([View Highlight](https://read.readwise.io/read/01m0tvvm5dfpt784akf17w4t0v)) - Note: The thesis. A stable equilibrium where competence at remediation is the mechanism sustaining the problem — the defect is the mismatch between visibility and authority. Swap in DevRel, docs, a11y, or QA and it holds unchanged. - Tags: atom/atomic/h1, devrel, organisational-design, incentives - Most teams see their own system. Engineering sees the platform. Brand sees the message. Product sees the problem it solves. Support sees the customer in front of them. SEO sees some of the joins and what leaks through them. ([View Highlight](https://read.readwise.io/read/01m0tvwhqfr4tt9h7nktznpb2f)) - Note: The positional explanation for why this function finds the failures. Visibility across the joins is what makes the diagnosis possible — and it's exactly the position that comes without authority to act on what it sees. - Tags: systems-thinking, atom/literature/h2, org-structure - Organisations are good at disguising these weaknesses as queues of work. Twenty bad product descriptions become twenty copy tickets. Ten slow templates become ten performance tickets. Dashboards turn green; the underlying problem remains gainfully employed. ([View Highlight](https://read.readwise.io/read/01m0tvvv9kg9fegr1bc8pzhnvy)) - Note: The mechanism by which structural weakness becomes invisible: decomposing one missing capability into many closeable tickets converts an unowned problem into measurable throughput. Metrics improve, cause persists. - Tags: organisational-design, measurement, capability-gaps, atom/atomic/h1 - The career incentives are unhelpful. Rescue a disastrous migration, and everybody knows about it. Make future migrations uneventful and, ideally, nobody notices. More involvement can look like influence when it really shows that the business cannot operate without supervision. The answer is not to supervise harder. It is to remove the failure from the process. ([View Highlight](https://read.readwise.io/read/01m0tvw2t5r7ys9f07xggj1xr4)) - Note: Why the trap survives contact with rational actors. Averted failures generate no evidence of themselves, so any incentive built on visible outcomes overpays for rescue and underpays for prevention. The appearance of influence is evidence of institutional weakness. - Tags: prevention, atom/atomic/h1, career, incentives - A useful handoff leaves behind enough understanding, tooling and accountability for the capability to survive without constant permission. If it collapses when the SEO lead takes six months off, it was dependency in a nicer outfit. The proof of a successful handoff is not that the meeting happened; it is that the same class of failure stops coming back. ([View Highlight](https://read.readwise.io/read/01m0tvwaar49fhfpbvnnzv7jeb)) - Note: A single falsifiable test for whether a capability actually transferred. Absence of the individual — not the occurrence of a handoff meeting — is the evidence. - Tags: atom/atomic/h1, handoff, bus-factor, institutional-knowledge