# Internal Advocacy Needs a Build-Break-Report Ritual ## Claim The voice of the developer only lands inside a company when it arrives as a repeatable ritual — rebuild the product from your own docs, run it for real, and file every discrepancy — not as accumulated impressions from doing support or reading feedback. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for any product with docs and a quickstart, where the advocate has enough engineering background to rebuild credibly. - Breaks down when findings have no routed backlog to land in — the ritual only pays off if docs/engineering teams actually receive and act on the report. - Does not establish a cadence; DeMars describes doing this as ongoing practice, not a measured interval. Whether weekly, sprint-based, or quarterly produces the best defect yield is untested here. ## Evidence Chris DeMars (TuxCare) describes taking off the "advocate hat," putting the "developer hat" back on, scaffolding a real app (e.g., Angular 15), running TuxCare's product against it, walking the docs for discrepancies, and reporting findings back to docs and engineering as a user rather than a colleague. He frames the credibility gate plainly: "have to be a developer first to be a developer advocate." ## Links - [[3. Resources/Permanent Notes/Friction Logging Is the DevRel Equivalent of Code Review]] — because extends; DeMars's ritual is a named instance of the same practice (walk the developer journey, log every gap between expected and actual behavior). - [[3. Resources/Permanent Notes/Time-to-Hello-World Is the Critical Developer Experience Metric]] — because applies-in; the ritual is how you actually catch regressions in the metric this note argues is the real DX signal. - [[3. Resources/MOCs/DevRel MOC]] — because applies-in; internal-advocacy practice is one of the MOC's core measurement/practice threads. ## Tests / falsifiers - Compare defect-discovery rate (docs/product bugs filed per quarter) between a DevRel team that runs a scheduled rebuild ritual and one that relies only on inbound community bug reports. - Check whether advocates without prior shipping experience can still produce actionable friction reports — if so, the "developer first" credibility gate is weaker than claimed. ## Maintenance - Last tended: 2026-08-16 - Next review: 2026-11-16 ## Source - [[3. Resources/Literature Notes/devrelshow ep 53 - Chris DeMars from TuxCare]] — reports the developer-hat workflow and the "developer first" credibility claim, ≈08:50–10:46 in the episode.