My Approach to DevRel Has Always Been Outside the Box
🔗 **Source:** [My Approach to DevRel Has Always Been Outside the Box](https://twitter.com/blackgirlbytes/status/2065591620162998517/?rw_tt_thread=True)
> [!note]+ Document Notes
> tags: [devrel, developer-advocacy, content-strategy, career-growth, technical-credibility, audience-building]
> author: Rizèl Scarlett (@blackgirlbytes)
> source: X / Twitter thread
> reference: https://twitter.com/blackgirlbytes/status/2065591620162998517/?rw_tt_thread=True
> date created: 2026-06-14 02:00
>
> # 🏷️ Title: My approach to DevRel has always been outside the box — unpopular DevRel opinions
>
<!-- deep-read:sections start -->
## 🧭 Table of Contents
- [📝 Summary](#-summary)
- [📖 Main Content](#-main-content)
- [🗒️ Notes](#️-notes)
- [📚 References](#-references)
- [🗣️ Paraphrase](#️-paraphrase)
- [📰 Newsletter](#-newsletter)
- [✅ Action Items](#-action-items)
- [🧪 Hypotheses](#-hypotheses)
- [📊 Methodology](#-methodology)
- [❓ Questions](#-questions)
- [🔮 Future Research](#-future-research)
- [💡 Implications](#-implications)
- [🧠 Learning Styles Assessment](#-learning-styles-assessment)
- [📊 Accessibility Assessment](#-accessibility-assessment)
- [🌍 DEIB Assessment](#-deib-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
### 🔗 References
- Original thread: https://twitter.com/blackgirlbytes/status/2065591620162998517/?rw_tt_thread=True
- Named exemplars: Claire Vo, Gergely Orosz, Lenny Rachitsky (podcast-host-as-expert model)
## 📝 Summary
- **What happened:** Rizèl Scarlett (blackgirlbytes) posted a thread of "unpopular" Developer Relations opinions drawn from her own practice.
- **Why it matters:** It's a concise, practitioner-level operating philosophy for DevRel — useful as a self-audit checklist for anyone in developer advocacy (directly relevant to GoDaddy/Airo DevRel work).
- **Key stakeholders:** Developer advocates, DevRel managers, community/content leads, ICs trying to build a personal brand inside a company.
- **Risks/tradeoffs:** Her "quantity can still be high-quality" stance cuts against hustle-culture critiques; "followers matter" cuts against the "vanity metrics" orthodoxy. Both are defensible but contested.
- **Bottom line:** Effective DevRel = technical depth + consistent, *valuable* output + external reach + internal usefulness, ideally anchored by a platform you own.
## 📖 Main Content
Scarlett frames her career approach as unconventional but execution-driven ("I execute with excellence so... trust me"). Her thesis bundles five operating principles:
1. **Dual effectiveness** — advocates must deliver value both externally (reach, content, audience) and internally (docs, repo issues, understanding the team's business needs). External-only is performative; internal-only is invisible.
2. **Technical depth is non-negotiable** — advocates (distinct from community managers) must stay deeply technical, because the target audience (developers) won't trust someone who can't speak to the tech. She explicitly separates this from being a "YouTube influencer."
3. **Consistency compounds** — repetition builds topic association and subject-matter-expert recognition; low engagement after switching companies is expected and temporary.
4. **Value gates consistency** — output without learning value is "just noise"; she advocates frequent self-evaluation ("is anyone learning from this?") and willingness to pivot. Cadence can be slow (monthly) if the audience learns to anticipate quality drops.
5. **Own your platform** — hosting your own podcast/livestream/space beats only guesting; it builds a trusting audience and lets you learn from guests. Cites Claire Vo, Gergely Orosz, Lenny as "household name" exemplars.
Contested claims she flags as "unpopular": followers *do* matter; quantity *can* be quality when it comes from real experimentation; advocates *should* be technical (a stance she says once made her "public enemy number 1").
### 🗒️ Notes
- Distinguishes Developer Advocate (must be technical) from community manager (need not be) — a role-scoping claim, not a value judgment.
- "Recognition is built through repetition" — the SME-by-association mechanism.
- Reframes the quantity-vs-quality binary: high output *grounded in real experimentation* can be both frequent and deep.
- Owning a platform has a compounding double benefit: audience trust + learning from guests.
- Internal effectiveness examples: write docs, manage repo issues, learn the team's business needs.
- Closing note signals a shifting norm: "everyone doesn't feel they're uncommon anymore" — the technical-advocate stance is becoming mainstream.
## 📚 References
- [Rizèl Scarlett on X (@blackgirlbytes)](https://twitter.com/blackgirlbytes)
- Claire Vo — host, *How I AI* / product leader (platform-owner exemplar)
- Gergely Orosz — *The Pragmatic Engineer* (platform-owner exemplar)
- Lenny Rachitsky — *Lenny's Podcast / Newsletter* (platform-owner exemplar)
## 🗣️ Paraphrase
- *Opener:* My DevRel style is unconventional, but I execute well — here are my unpopular opinions.
- *Tweet 2:* Advocates should be effective inside and outside the company; external reach (yes, followers) matters because undiscovered content is pointless.
- *Tweet 3:* Stay deeply technical — developers won't trust an advocate who doesn't understand the tech; this isn't influencer work.
- *Tweet 4:* Consistency is a major career edge; recognition comes from repetition, and high output can still be technical and useful.
- *Tweet 5:* But consistency without value is noise — evaluate whether people are learning, and pivot if not.
- *Tweet 6:* Owning your own platform (podcast/livestream) establishes expertise faster than only guesting.
- *Tweet 8:* Don't forget internal effectiveness — docs, repo issues, understanding business needs.
- *Tweet 9:* The "advocates should be technical" stance used to be controversial; now it feels common.
## 📰 Newsletter
For the WordPress crowd: blackgirlbytes' DevRel thread reads like a contributor-day pep talk. Her "consistency without value is just noise" line is a clean rule for anyone shipping Learn WordPress tutorials, Core dev notes, or community livestreams — publishing on schedule isn't the win; people *learning* is. And her "own your platform" point maps neatly onto WordPress's open ethos: a self-hosted blog or a recurring community stream compounds trust in a way that guest spots alone never will. Worth a read if you advocate for *anything* technical.
## ✅ Action Items
#### DevRel
- Developer advocacy: audit current output against her two-axis test (external reach AND internal usefulness); log one internal contribution (docs/repo issue) per sprint.
- Education: build a monthly "drop" cadence the audience can anticipate, gated on a learning-value check rather than a fixed quota.
- Developer experience: convert recurring questions into owned-platform episodes (livestream/podcast) instead of one-off guest spots.
- Developer marketing: track discovery/engagement as a legitimate signal (her "followers matter" point), not a vanity metric to dismiss.
- Community management: clarify role scope — advocate (technical) vs community manager (non-technical) — in team charters.
- Internal/external/cross-project: map the team's business needs and align advocacy output to them.
#### OSPO
- Developer Support: encourage advocates to manage upstream repo issues as a measured part of their role.
- Strategic Alignment: tie DevRel KPIs to learning outcomes, not publish counts.
#### Community
- Maintainers: model "own the platform" by hosting recurring project office hours.
- Contributors: use repetition (recurring contribution slots) to build SME recognition.
#### WordPress
- Training: apply the "value gates cadence" rule to Learn WordPress release schedules.
- Documentation: frame docs work as legitimate DevRel internal-effectiveness output.
- Marketing: anticipate-the-drop model for community content calendars.
- Community: coach WordCamp speakers on technical credibility as trust currency.
#### The WPCC
- Programs: stipend recurring community-stream hosts (owned-platform model).
#### FAIR
- Not applicable to this source — no governance/independence content in the thread.
## 🧪 Hypotheses
- H1: Advocates who maintain visible technical depth earn higher developer trust/engagement than non-technical content-only advocates.
- H2: A predictable, lower-frequency cadence (e.g., monthly) with high learning value outperforms high-frequency low-value output on audience retention.
- H3: Advocates who own a platform (podcast/stream) reach SME recognition faster than those who only guest.
- H4: Engagement/followers correlate with measurable business outcomes, contradicting the "followers don't matter" position.
- H5: Internal contributions (docs, repo issues) increase an advocate's longevity/role security independent of external reach.
### 📊 Methodology
- Test H1/H4 with engagement + trust surveys segmented by advocate technical depth; correlate with funnel/attribution data.
- Test H2 via A/B cadence experiments measuring 90-day retention and learning self-reports.
- Test H3 with a cohort study tracking time-to-SME-recognition for platform-owners vs guests.
- Test H5 via tenure analysis controlling for external reach.
### ❓ Questions
- Where exactly is the line between "technical enough" and "deeply technical" for an advocate?
- Does "followers matter" hold equally across B2B developer tools vs consumer-dev audiences?
- What's the minimum viable owned platform before it compounds?
- How do you measure "is anyone learning from this?" without heavy instrumentation?
### 🔮 Future Research
- Comparative study of DevRel career trajectories by technical-depth investment.
- Frameworks for "learning value" metrics in developer content.
- The shifting norm: is technical-advocate expectation now industry-standard, and what displaced the prior view?
### 💡 Implications
- **Practice:** Self-audit DevRel work on two axes (reach + internal usefulness) and on value-not-volume.
- **Policy:** Role definitions should explicitly scope technical expectations for advocates vs community managers.
- **Education:** Cadence design should be value-gated, not quota-driven.
- **Funding:** Owned platforms are worth investing in for compounding trust returns.
### 🧠 Learning Styles Assessment
- Reading level estimate: ~Flesch-Kincaid Grade 7–8 (casual, conversational, short sentences with informal spelling like "lmaoo," "DUHHH").
#### 👀 Visual learners
- Present: none (text-only thread).
- Improve: a 2x2 (reach × usefulness) or a cadence-vs-value matrix would crystallize the argument.
#### 🔊 Aural learners
- Present: none.
- Improve: a short audio reading or podcast riff on the five principles.
#### 🗣️ Verbal learners
- Present: strong — analogies, named exemplars, plain language.
- Improve: define "deeply technical" with a concrete bar.
#### 🧩 Kinesthetic learners
- Present: implicit (do docs, manage issues).
- Improve: a self-audit checklist to apply immediately.
#### 🧠 Logical learners
- Present: clear principle → reasoning → caveat structure.
- Improve: a decision tree for "publish or pivot?"
#### 🧑🤝🧑 Social learners
- Present: thread invites replies/debate ("unpopular opinions").
- Improve: discussion prompts per principle.
#### 🧘♀️ Solitary learners
- Present: reflective framing ("is anyone learning from this?").
- Improve: journaling prompts for a personal DevRel audit.
#### 🌿 Naturalistic learners
- Present: none.
- Improve: ecosystem framing (advocacy as part of a community lifecycle).
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: plain text reads cleanly; emoji flags in source are minimal.
- Improve: thread platform should expose per-tweet structure; no images need alt text here.
#### Keyboard navigation
- Not applicable to this source — platform-controlled (X), not author-controlled.
#### Contrast and readability
- Present: platform default.
- Improve: N/A at author level.
#### Text resizing and reflow
- Not applicable to this source — handled by the X client.
#### Media and captions
- Not applicable to this source — no embedded media in the thread text.
#### Forms and interactions
- Not applicable to this source — no forms.
#### Standards reference
- Minimal author-side WCAG 2.2 AA surface; the main gap is informal spelling that may challenge non-native readers (3.1.5 Reading Level).
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: author flags Antigua/Barbuda & Guyana heritage in handle; perspective is from an underrepresented voice in tech.
- Improve: examples are US-tech-centric (named hosts are all US-based).
#### Inclusive language
- Present: respectful, no exclusionary terms; casual register lowers gatekeeping tone.
- Improve: define jargon (DevRel, SME) for newcomers.
#### Neurodiversity support
- Present: short, chunked tweets; consistent one-principle-per-tweet structure.
- Improve: a summary list at the top would aid orientation.
#### Representation
- Present: a Black woman engineer asserting technical authority directly counters DevRel stereotypes; the "public enemy number 1" line names the bias she faced.
- Improve: none needed; representation is a strength here.
#### Psychological safety
- Present: vulnerable, humorous framing invites disagreement without hostility.
- Improve: N/A.
### ✅ Logical Validity
#### Strong reasoning
- **Conditional/analogical (Tweet 6):** "hosting my own... is even better" supported by the household-name exemplars (Vo, Orosz, Lenny) — a clean inductive generalization from recognized cases.
- **Causal (Tweet 4):** "Recognition is built through repetition" — plausible mechanism (association → SME perception), consistent with mere-exposure effects.
- **Self-correcting (Tweet 5):** the value-gate caveat pre-empts the obvious objection to the consistency claim, strengthening the overall argument.
#### Fallacies
- **Appeal to authority / hasty generalization (mild), Tweet 6:** three famous hosts are cited as proof that owning a platform establishes expertise — survivorship bias (we don't see the many platform-owners who didn't break through). *Fix:* pair exemplars with base rates or a counterexample.
- **Anecdotal evidence, throughout:** principles are generalized from the author's single career ("happens to me every time I switch companies"). *Fix:* frame as hypotheses (as done above) rather than universal rules.
#### Tone of voice
- Confident, candid, humorous, self-aware ("lmaoo," "DUHHH," "public enemy number 1 😂"). Persuasive-personal rather than academic; deliberately positions claims as "unpopular opinions" to invite engagement.
### 🛡️ DARVO Analysis
- Not applicable to this source — the thread is an opinion/advice piece with no accusation-and-defense dynamic. The closest rhetorical move is recounting past pushback ("public enemy number 1"), which is self-reflection, not Deny/Attack/Reverse-victim-offender.
## 🎯 Conclusion
- **Bottom line:** Good DevRel is technical depth + consistent, genuinely valuable output + external reach + internal usefulness, compounded by owning a platform.
- **Next steps for readers:** Run the two-axis self-audit, design a value-gated cadence you can sustain, and start (or invest in) one platform you own. Treat her universal-sounding rules as testable hypotheses for your own context.
## 🔄 Refactor Appendix — My approach to DevRel has always been outside the box
### 📚 Literature Atoms (H3)
### [H1] Developer advocates must stay deeply technical to earn trust
> [!quote] ID:rw_blackgirlbytes_technical
> Why would a developer (my target audience) trust me if I dont know what's going on?
**Context & use**:
- Tweet 3 of the thread.
- Technical credibility is the trust currency of advocacy; separates advocate from community manager.
**Tags**: #xref #aphorisms
<!-- atomicity: 1 idea ✓ -->
### [H2] Consistency without value is just noise
> [!quote] ID:rw_blackgirlbytes_noise
> Consistency without value is just noise. Publishing every week does not automatically make my work useful.
**Context & use**:
- Tweet 5; the value-gate that qualifies the consistency principle.
- Self-evaluation ("is anyone learning from this?") gates cadence.
**Tags**: #xref #aphorisms
<!-- atomicity: 1 idea ✓ -->
### [H3] Owning a platform establishes expertise faster than guesting
> [!quote] ID:rw_blackgirlbytes_platform
> One of the fastest ways I've established expertise is by creating my own platform/space/podcast/livestream.
**Context & use**:
- Tweet 6; double benefit — audience trust + learning from guests.
- Exemplars: Claire Vo, Gergely Orosz, Lenny.
**Tags**: #xref
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates (H4)
#### [P1] Value gates cadence in content work
**Claim** (one sentence, Courtney's voice): Publishing on schedule only compounds trust when each drop teaches the audience something.
**Evidence pointer**: [[#H2]]
**Scope & conditions**: Holds for audience-building/educational content; breaks when the goal is pure presence/SEO volume.
**Links** (≥1 with annotation):
- [[Developer Relations]] — because applies-in DevRel practice
- [[Progressive Summarization]] — because contrasts on volume-vs-value
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Does "followers matter" hold for B2B dev-tools as strongly as consumer-dev? — thread Tweet 2 #fleeting #inbox
- [F2] Build a reusable DevRel two-axis (reach × internal usefulness) self-audit checklist — #fleeting #inbox
### → Things 3 (max 2 actions)
- [ ] Draft a value-gated monthly content cadence for Airo DevRel — content #things
- [ ] Audit one current advocacy output against the reach × usefulness test — devrel #things
<!-- deep-read:sections end -->
📄 **Full text:** ![[Full Document Contents/Tweets/My Approach to DevRel Has Always Been Outside the Box.md|My Approach to DevRel Has Always Been Outside the Box by Rizèl Scarlett 🇦🇬🇬🇾]]
## Highlights
- Developer Advocates should stay deeply technical. This is not including community managers etc..people who dont need to do the tech things. ([View Highlight](https://read.readwise.io/read/01kv3svsvkgfxv6tbzx3csg4qn))
- Note: Central thesis: advocates (unlike community managers) must stay deeply technical — it's the trust currency with a developer audience.
- Tags: atom/literature/h1, developer-advocacy, technical-credibility
- Consistency is one of the biggest career advantages in DevRel. ([View Highlight](https://read.readwise.io/read/01kv3svyspapwfx98bas6zsqb7))
- Note: Recognition is built through repetition; low engagement after a company switch is expected and temporary.
- Tags: atom/literature/h2, consistency, career-growth
- Consistency without value is just noise. Publishing every week does not automatically make my work useful. ([View Highlight](https://read.readwise.io/read/01kv3sw2w63qnzwdmj13qcsb7a))
- Note: The value-gate that qualifies the consistency principle: self-evaluate ("is anyone learning from this?") and pivot if not.
- Tags: atom/literature/h2, content-strategy, value-over-volume
- One of the fastest ways I've established expertise is by creating my own platform/space/podcast/livestream. ([View Highlight](https://read.readwise.io/read/01kv3sw7m4sjbrk09mv3bspt75))
- Note: Owning a platform beats only guesting — double benefit: build a trusting audience + learn from guests. Exemplars: Claire Vo, Gergely Orosz, Lenny.
- Tags: owned-platform, audience-building, atom/literature/h2