devrelshow episode 52 - Joel Hans from ngrok 🔗 **Source:** [devrelshow episode 52 - Joel Hans from ngrok](https://www.youtube.com/watch?v=uQ4KmED0Mlg#transcript) > [!note]+ Document Notes > tags: [developer-relations, brand-marketing, developer-education, networking-fundamentals, content-strategy, workplace-autonomy, career-change] > author: Frédéric Harper > source: devrelshow (YouTube) > reference: https://www.youtube.com/watch?v=uQ4KmED0Mlg#transcript > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: devrelshow episode 52 - Joel Hans from ngrok > <!-- 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) ## 📝 Summary - Frédéric Harper interviews Joel Hans, Developer Relations Lead at ngrok, about how his role has quietly turned into brand marketing, and about a personal networking-fundamentals project he's using to relearn the internet from the wire up. - Joel started at ngrok as a "senior developer advocate" writing deep technical content (a widely-cited piece on ngrok's traffic policy language), then over about two years watched the job shift toward re-establishing ngrok's brand perception — countering the outdated "just a tunneling tool" reputation and competing for mindshare against self-hosted alternatives and AI coding agents that default to whatever tool they already "know." - Fred draws a direct parallel from his own role at TinyMCE: a 20+ year old product that people assume is dead, so a large share of his DevRel job is now pure awareness-building, not documentation or activation. - Both agree the deciding factor for whether people even consider a tool now is whether it exists in a developer's (or their AI agent's) mental map at all — onboarding polish matters less than getting into the "unaided consideration set" in the first place. - Their shared prescription: publish genuinely useful, product-unrelated "cornerstone" content (Joel cites a teammate's 7,000-word piece on LLM quantization) that earns attention on its own merits and pays off in brand recall months later, rather than chasing weekly content quotas that produce burnout and mediocre output. - Joel demos "Little Internet," his own raspberry-pi networking lab (github.com/ngrok/little-internet), where he's teaching himself Ethernet link states, IPv6 neighbor discovery, and ARP by physically wiring Pis together and watching packets — framed explicitly as a sanctioned "folly" (a nod to Walt Disney's Disneyland gamble) rather than a KPI-bound deliverable. - Risks/tradeoffs: this style of DevRel is hard to justify to a business that wants fast, measurable ROI; it depends on a high-trust relationship between DevRel and leadership, and its payoff (perception shift, brand recall) is genuinely difficult to attribute to revenue. - Bottom line: as AI-assisted development and TL;DR culture compress the middle of the funnel (onboarding, docs, activation), DevRel's most defensible value is now at the very top of the funnel — being remembered, trusted, and interesting enough to be in the running at all. ## 📖 Main Content - **The role keeps shifting under people's feet.** Joel notes he's had three employer names in under two years without changing jobs (Cube first → Constant Contact-owned entity → absorbed into Seva), and frames DevRel generally as uniquely unstable compared to adjacent engineering roles: an engineer's job looks similar wherever they go, but "developer relations" can mean ten different job descriptions depending on the company and the quarter. - **DevRel as "10-20 jobs in one."** Joel likes the variety (advocate, support engineer, community manager, public speaker, content producer) but names it as also the role's core fragility — priorities can reset entirely when leadership or company strategy shifts. - **Joel's arc at ngrok.** He joined as a "senior developer advocate," his early wins were deep technical writing (a "10 things you didn't know you could do with traffic policy" post that surprised ngrok's own engineers) plus some live-stream demos and product-marketing video. By year two, the job had drifted far enough from classic DevRel that he says "I'm not really a DevRel person anymore," even though his team is still called developer relations/education. - **Why the shift happened: ngrok has a stale-brand problem.** People who've heard of ngrok often still picture it as "the tool that tunnels my localhost to share with a friend" — true, and still the majority of daily signups — but ngrok now positions itself as production API-gateway infrastructure (DDoS protection, WAF, full gateway). The DevRel team's real job right now is closing that perception gap, not teaching people how to use features. - **Fred's TinyMCE parallel.** TinyMCE predates Gutenberg, is still used in Moodle and Umbraco, and suffers the same "I didn't know you were still around" reaction at conferences. Fred says a big chunk of his job is back to first-principles awareness: reminding the market the product exists and is actively maintained, often via content that doesn't even mention the product. - **AI coding agents change the awareness calculus.** Joel observes a steady stream of "I built an ngrok alternative you can self-host" posts on Hacker News/Reddit/Twitter, and argues that if a tool isn't already inside a developer's (or their coding agent's) frame of reference, it never enters consideration — the agent just picks whatever it already "knows," and the human doesn't do the comparison shopping that used to happen manually. - **Onboarding/activation is being deprioritized relative to top-of-funnel awareness.** Joel frames this as a historical inversion: DevRel used to be measured heavily on reducing time-to-activation/"aha moment"; now, with abundant competing options, simply getting into the funnel at all is the harder, more important problem. - **"Cornerstone" content as the new lever.** Joel's team (three people, including "phenomenal writer" Sam Rose) is deliberately producing long-form, product-unrelated educational content — e.g., a 7,000-word explainer on LLM quantization — betting that genuine expertise and craftsmanship earns attention and recall now, purchase consideration later. He's explicit that he doesn't know for certain it will pay off, but the team is committed to the bet. - **Explicit anti-calendar, anti-quota stance.** Joel names forcing a fixed cadence of content ("x pieces per week/month") as actively dangerous — it produces burnout and subpar, deadline-driven work — and says he's negotiated with leadership toward measuring long-term brand impact instead of output volume. - **"Side quests" reframed as sanctioned "follies."** Joel used to offer new hires "side quest" time but felt that framing implied extra unpaid effort. He now uses Walt Disney's "Disney's Folly" (the wildly expensive, uncertain Disneyland gamble) as the model: leadership grants time/space for speculative work with no guaranteed payoff, on the belief that even failed follies produce learning and that trying strange things beats uniform, me-too content. - **How he got buy-in.** Joel is careful not to claim he invented the culture — leadership (particularly his CRO) already recognized brand perception as a top-level business problem before he pitched anything; his role was more "lead by example," building a track record (engagement, comments, unsolicited "I hadn't heard of ngrok but their posts are good" feedback) that lets him keep making the case. - **Trust as the load-bearing variable.** Both hosts converge on the idea that this style of DevRel only works in a high-trust relationship with leadership — without it, DevRel reverts to KPI-driven content-mill work, which both frame as a common failure mode across the industry. - **The "Little Internet" demo.** Joel wires two Raspberry Pis together with an Ethernet cable and walks through, live, the actual mechanics of getting them to talk: interface state changes (down → up), IPv6 neighbor discovery/mDNS traffic showing up before the devices can actually reach each other, manually assigning IP addresses, and finally watching ARP negotiate MAC-address-to-IP mappings so ping succeeds. He's also built OLED displays that visualize each Pi's live ARP cache/state machine. The project lives at github.com/ngrok/little-internet, including scripts to reproduce the setup in VMs for people without spare hardware. - **Why a networking company DevRel is doing this personally.** Joel frames it as motivated self-education (he didn't deeply understand the protocols underneath his own product) that doubles as brand-safe content: teaching fundamentals of "the most durable thing in the AI era" (the internet itself) reinforces ngrok's positioning as an infrastructure-literacy company, without being a product pitch. <a id="️-notes"></a> ## 🗒️ Notes #### 🧭 DevRel role instability and the "many jobs in one" problem - Joel: the role's ground is "always shifting under your feet" — quarter to quarter the mandate can change entirely, unlike engineering roles where the job stays constant across employers. - He had three company names in under two years purely from acquisitions (Cube first → absorbed entity → Seva), without ever changing jobs himself. - Both hosts agree DevRel absorbs functions (advocate, support, community, speaker, marketer) that would be separate roles anywhere else — the versatility is also the instability. #### 📈 From technical expert content to brand perception work - Joel's early ngrok wins were deep-dive technical writing (the traffic-policy post) and demo/video content — classic "be the product expert" DevRel. - By year two the job had migrated toward brand perception management: ngrok's stale "just a tunnel" reputation versus its current positioning as production API-gateway infrastructure (DDoS protection, WAF). - Fred: TinyMCE has an almost identical problem — a mature, still-maintained product that the market assumes is obsolete or abandoned; a large share of his job is now pure "we still exist and we're good" awareness work, often unbranded. #### 🤖 AI agents and the collapse of manual tool discovery - Joel monitors social mentions and sees near-daily "I built an ngrok alternative" posts; his worry is that AI coding agents default to whatever tool is already in their training/context, so a brand absent from that frame of reference is never even considered, let alone evaluated. - This reframes the DevRel priority stack: classic funnel metrics like time-to-activation matter less than simply being present in the option set before a human or an agent starts building. #### ✍️ Cornerstone content as a deliberate, unmeasured bet - Team member Sam Rose wrote a 7,000-word piece on how LLM quantization works — intentionally unrelated to ngrok's product — as a bid for recall value ("oh yeah, I remember reading that, maybe I should check them out"). - Joel is candid that he doesn't know if this pays off, but frames the willingness to not know, and to still ship it, as itself the point. - Fred adds the "medium to long-term impact" framing: DevRel's actual ROI horizon is months, which is hard to reconcile with a business that wants fast, attributable returns. #### 🚫 Rejecting calendar-driven content quotas - Joel names fixed output quotas ("x posts per week/month") as actively harmful — a direct driver of burnout and of shipping subpar work just to hit a deadline. - He's negotiated with leadership to protect against this, prioritizing long-tail brand impact over cadence. #### 🎢 "Folly" as sanctioned risk-taking (the Disney reframe) - Joel discarded the "side quest" framing (it implied uncompensated extra work) in favor of Walt Disney's "Disney's Folly" — Disneyland as a wildly expensive, uncertain bet that leadership funded anyway. - The point isn't guaranteed success; it's that leadership grants the time/space to attempt something risky, and even a failure produces a lesson and (per Fred) helps a team "fail faster" on the next bet. - Joel is candid that internal buy-in came less from him pitching the idea and more from leadership already sensing the brand-perception problem, and from building a track record other team members could point to. #### 🤝 Trust as the prerequisite for DevRel autonomy - Both hosts converge on: this kind of experimentation-friendly DevRel only survives inside a high-trust relationship with leadership; without that trust, DevRel reverts to KPI-bound content production, which both describe as a common industry failure mode. #### 🌐 Demo: "Little Internet" — relearning networking from Raspberry Pis up - Joel connects two Raspberry Pis with an Ethernet cable live on stream and narrates each diagnostic step: interface state flips from down to up, IPv6 neighbor discovery/mDNS traffic appears even though the devices can't yet reach each other, manual IP assignment, then ARP negotiating MAC-to-IP mappings until ping finally succeeds. - He built physical OLED displays that visualize each Pi's live ARP cache state machine, aiming to make an invisible protocol tangible. - Project and reproducible VM scripts live at github.com/ngrok/little-internet, explicitly built for people without spare hardware. - Framed as both genuine self-education (he didn't understand these fundamentals despite working at a networking company) and low-risk brand content: teaching "the internet, the most durable thing in the AI era" reinforces ngrok's infrastructure credibility without pitching the product. ## 📚 References - [devrelshow YouTube video](https://www.youtube.com/watch?v=uQ4KmED0Mlg) — full episode and transcript source - [ngrok/little-internet](https://github.com/ngrok/little-internet) — Joel's Raspberry Pi networking-fundamentals project and reproducible VM scripts - [ngrok](https://ngrok.com) — Joel's employer; API gateway / secure tunneling infrastructure - [TinyMCE](https://www.tiny.cloud) — Fred's employer; rich-text editor referenced as a parallel legacy-brand-perception case ## 🗣️ Paraphrase - Joel's core argument: DevRel used to be graded on how smoothly it moved a developer from curiosity to activation. Now that developers (and their AI coding agents) have an overwhelming number of options and increasingly outsource the comparison-shopping itself, the harder and more valuable problem is getting into consideration at all — which turns a technical-advocacy job into something closer to brand marketing. - Fred's core argument: mature products carry a reputational tax — the market assumes stagnation or abandonment by default — so a meaningful share of DevRel's job for an incumbent product is just proving continued relevance, independent of any specific feature or doc. - Together: cornerstone content (genuinely useful, product-unrelated work) is the mechanism both are betting on to fight that reputational tax and win attention in an AI-mediated discovery landscape, even though its payoff is slow and hard to measure — which is why protecting DevRel from rigid content quotas, and giving it "folly" budget, matters more than it used to. ## 📰 Newsletter - Two DevRel leads compare notes on a quiet shift happening across the field: helping developers succeed with your docs matters less right now than making sure your product is even in the running — especially now that AI coding agents pick tools from whatever they already "know." - If your product is mature (hello, WordPress plugin and theme authors with a decade-plus in the changelog), this episode is a useful gut-check: are you still investing in "we still exist and we're good" content, or did that awareness work quietly stop a few years ago? - Practical takeaway for community and plugin maintainers: consider a genuinely useful, product-unrelated "cornerstone" post or resource as a low-risk way to earn attention and goodwill — and resist the urge to grade your content team purely on cadence. - Also worth a look: ngrok's [Little Internet](https://github.com/ngrok/little-internet) project, a fun, hands-on way to relearn Ethernet/ARP/IPv6 fundamentals with nothing more than a couple of Raspberry Pis (or a VM if you don't have the hardware). ## ✅ Action Items #### DevRel - Developer advocacy: audit current content calendar for rigid cadence requirements; propose replacing fixed weekly/monthly quotas with a long-tail brand-impact framing, following Joel's negotiated model with ngrok leadership. - Education: scope one "cornerstone" piece — long-form, genuinely useful, and not a product pitch — modeled on Sam Rose's quantization post, to earn attention independent of the product. - Developer experience: none surfaced directly (this episode is explicitly about de-prioritizing onboarding/activation work relative to top-of-funnel awareness). - Developer marketing: build a lightweight qualitative-evidence log (unsolicited mentions, "I hadn't heard of you but liked this post" comments) to use as buy-in evidence with leadership, mirroring Joel's approach. - Community management: not directly addressed in this episode. - Internal/external/cross-project: pitch a "folly" allowance to leadership — protected time for a speculative, unmeasured project — framed explicitly around learning value rather than guaranteed ROI. #### OSPO - Not applicable to this source — the episode does not discuss open-source program office governance, licensing, or software supply-chain topics. #### Community - Not applicable to this source — no maintainer/contributor/sponsor community topics were discussed. #### WordPress - Not applicable to this source — TinyMCE is referenced only as a Gutenberg-predecessor rich-text editor and legacy-brand parallel; no WordPress-specific action surfaced. #### The WPCC - Not applicable to this source — not discussed. ### FAIR - Not applicable to this source — not discussed. ## 🧪 Hypotheses - H1: Teams that replace fixed content-cadence quotas with long-term brand-impact framing will see lower DevRel team turnover/burnout over a 12-month period. - H2: Product-unrelated "cornerstone" content drives more unaided brand recall (measured via survey or social listening) than product-specific content, at a 3-6 month lag. - H3: Mature/legacy developer tools that do not actively invest in "we still exist" awareness content see declining unaided brand recall among new-to-market developers, independent of product quality. - H4: The presence (or absence) of a tool in AI coding agents' training/context data measurably predicts its inclusion in a developer's initial "options considered" set. - H5: DevRel functions operating under explicit leadership-granted "folly" time (unscheduled, unmeasured speculative work) report higher job satisfaction than those held to fixed content-output KPIs. ### 📊 Methodology - H1/H5: paired surveys (burnout inventory, job satisfaction) across DevRel teams segmented by whether they operate under fixed quotas versus outcome/brand framing; control for team size and company stage. - H2/H3: social-listening and brand-recall panel studies (aided/unaided recall) before and after publication of a cornerstone piece, with a matched control period of product-specific content. - H4: prompt a sample of popular coding-assistant models with open-ended infrastructure/tooling questions across categories (tunneling, API gateways, etc.) and measure mention rate against actual market share/GitHub stars. ### ❓ Questions - How do you attribute revenue or pipeline to a cornerstone piece that never mentions the product, without falling into post-hoc storytelling? - Is the "folly" model sustainable past the team's current 3-person scale, or does it require a level of leadership trust that erodes as a DevRel org grows? - What happens to this strategy if/when AI search and coding agents start summarizing cornerstone content instead of driving traffic to the original post — does the recall mechanism still work if the reader never visits ngrok's site? - How do you distinguish "we're being intentionally exploratory" from "we lack goals," when explaining the strategy to a skeptical new VP or board member? ### 🔮 Future Research - Longitudinal tracking of ngrok's and TinyMCE's brand-perception metrics against their cornerstone-content publishing cadence, to see if the hypothesized recall effect is measurable at all over a 1-2 year horizon. - Comparative study of DevRel burnout rates under quota-driven versus outcome-driven management models. - Research into how coding agents actually select or recommend third-party tools/services, and what content types (if any) influence that selection. ### 💡 Implications - Practice: DevRel job descriptions and success metrics may need to shift from documentation/activation quality toward top-of-funnel brand-recall work, which requires different skills (long-form writing, brand storytelling) than classic technical advocacy. - Policy/management: protecting "folly" time requires an explicit leadership commitment that isn't self-sustaining — it depends on named executive sponsors (Joel cites his CRO), which is a single point of failure if that sponsor leaves. - Security: not directly addressed in this episode. - Education: cornerstone content aimed at general technical literacy (e.g., networking fundamentals, LLM quantization) may function as a durable education-marketing hybrid, useful for other technical brands with legacy-perception problems. - Funding models: this strategy assumes a company can tolerate multi-month, hard-to-attribute ROI — likely infeasible for very early-stage or cash-constrained startups. ### 🧠 Learning Styles Assessment - Reading level estimate: approximately Flesch-Kincaid grade 7-8. This is an unedited spoken transcript (informal diction, run-on sentences, frequent hedges like "I feel like," "you know") which reads easier than its actual conceptual density (brand strategy, network protocols) would suggest for a polished article. #### 👀 Visual learners - Present: the live ARP/networking demo is inherently visual (screen-share of terminal output, OLED status displays) though the transcript itself has no diagrams or screenshots. - Improve: a companion diagram showing the Ethernet → IPv6 neighbor discovery → ARP → successful ping sequence would make the demo's logic legible without watching the video. #### 🔊 Aural learners - Present: this is a podcast/livestream by nature — full audio available at the source video. - Improve: a 2-3 minute audio pull-quote summarizing the brand-marketing thesis would help listeners who want the takeaway without the full 59 minutes. #### 🗣️ Verbal learners - Present: strong use of analogy (Disney's Folly, "square peg in a round hole" for KPI culture) and plain-language definitions of DevRel sub-roles. - Improve: a short glossary distinguishing "developer advocate," "developer educator," and "brand marketing" as used in this episode would help readers unfamiliar with DevRel job-title variance. #### 🧩 Kinesthetic learners - Present: the Little Internet project is explicitly hands-on and reproducible (VM scripts provided for people without hardware). - Improve: a step-by-step lab guide alongside the GitHub repo would lower the barrier for someone wanting to replicate the ARP demo themselves. #### 🧠 Logical learners - Present: Joel's causal chain (mature-product perception problem → competition from self-hosted alternatives and AI agent defaults → need for top-of-funnel brand investment) is laid out clearly, if conversationally. - Improve: a simple funnel diagram (awareness → consideration → activation) annotated with where classic DevRel metrics used to focus versus where Joel argues focus should shift now would sharpen the argument. #### 🧑‍🤝‍🧑 Social learners - Present: the format itself is a peer conversation between two DevRel practitioners comparing notes across companies. - Improve: a discussion prompt ("does your org protect folly time? how do you sell it internally?") could extend this into a community Q&A. #### 🧘‍♀️ Solitary learners - Present: reflective, self-critical asides from both hosts (Joel questioning whether his approach is "clever" or arbitrary). - Improve: a short self-assessment checklist ("is my content calendar quota-driven or outcome-driven?") for a DevRel lead reading solo. #### 🌿 Naturalistic learners - Present: none directly, though the "internet as durable infrastructure" framing gestures at systems-thinking. - Improve: an explicit systems/ecosystem framing of how brand perception, product reality, and developer trust interact over time could appeal to this learning style. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: this note's own heading structure provides landmarks; the original source is a livestream transcript with no inherent headings. - Improve: if published as a companion article, add descriptive headings per topic segment (as done in this note's Notes section) rather than leaving it as one long transcript block. #### Keyboard navigation - Not applicable to this source — it is a video/audio recording, not an interactive interface. #### Contrast and readability - Not applicable to this source in its transcript form; would apply only to any web page hosting the video/transcript. #### Text resizing and reflow - Not applicable to this source directly; applies to the hosting page, not the transcript content itself. #### Media and captions - Present: a transcript exists (this is it), which is itself a captioning/accessibility artifact. - Improve: the transcript has no timestamps and no speaker labels beyond inferred turn-taking; adding speaker diarization and timestamps would materially improve accessibility for anyone navigating by topic rather than reading start-to-finish. #### Forms and interactions - Not applicable to this source — no forms or interactive elements involved. #### Standards reference - Primary WCAG-relevant gap: 1.2.2 (Captions) is nominally met via the transcript, but 1.2.9 (Audio-only, live) and general navigability would benefit from timestamps/chapters, which are absent here. ### 🌍 DEIB Assessment #### Cultural breadth - Present: none directly — both speakers appear to represent a similar Western tech-industry DevRel context; no international or multilingual community examples are discussed. - Improve: could include perspectives from DevRel practitioners in non-English-first developer markets, where "brand awareness" dynamics with AI coding agents may differ significantly. #### Inclusive language - Present: casual, largely gender-neutral language throughout; no exclusionary terms noted. - Improve: minor jargon (KPI, funnel, top-of-funnel) is used without definition — a plain-language glossary would help readers newer to marketing/DevRel terminology. #### Neurodiversity support - Present: conversational chunking by topic, though as a raw transcript the piece runs long without structural breaks. - Improve: this note's own topic-segmented Notes section is exactly the kind of restructuring that would help — consistent headings, predictable pattern per topic. #### Representation - Present: two men in technical DevRel roles; no other voices represented in this particular episode. - Improve: not a flaw of this episode specifically, but a broader observation — the source show could actively seek a wider range of guest voices (gender, seniority, region) across its catalog. #### Psychological safety - Present: notably strong — both speakers openly discuss burnout, the discomfort of unmeasurable work, and self-doubt ("is this clever or am I just fooling myself") without defensiveness. - Improve: none needed; this is a strength of the source. ### ✅ Logical Validity #### Strong reasoning - Causal reasoning, "AI agents and tool discovery": Joel's argument that AI coding agents default to whatever tool is already in their frame of reference, and therefore skip the human comparison-shopping step, is a coherent causal mechanism connecting a specific behavior he observes (rising self-hosted-alternative posts) to a broader strategic conclusion (top-of-funnel awareness now matters more than onboarding polish). It's strengthened by naming a concrete, checkable phenomenon (social monitoring of competitor posts) as evidence. - Analogical reasoning, "Disney's Folly": using a well-documented historical case (Disneyland as an expensive, uncertain executive bet that paid off) to justify sanctioned speculative work is a strong analogy because the disanalogy is also acknowledged — Joel doesn't claim guaranteed success, only that leadership granted time and the attempt itself has value, which matches how he frames his own team's cornerstone-content bet. #### Fallacies - Hasty generalization (mild), "the biggest challenge of DevRel...": both speakers repeatedly generalize from personal/company experience ("I only have one job... I don't know what's happening everywhere") to industry-wide claims about how DevRel has changed. Fred explicitly flags this limitation himself mid-conversation, which mitigates but doesn't eliminate it — a fix would be citing outside data (surveys, other guests' experiences) rather than two data points. - Appeal to anecdote, the unsolicited-comment evidence: Joel cites occasional reader comments ("I just heard about ngrok... they write cool blog posts") as evidence the cornerstone-content strategy is "working." This is suggestive but not rigorous evidence of causal impact on business outcomes — a stronger claim would require the brand-recall or attribution methodology sketched in the Hypotheses section above. #### Tone of voice - Conversational, self-deprecating, and reflective throughout ("maybe I'm blabbering," "as much as I'd like to claim credit"); notably low on hype or absolutist claims, with both speakers routinely hedging their own generalizations. ### 🛡️ DARVO Analysis - Not applicable to this source — this is a collegial, non-adversarial interview with no accusation, denial, attack, or victim/offender reversal dynamic present. ## 🎯 Conclusion - The bottom line: as AI-mediated tool discovery and an oversupplied content landscape erode the value of classic DevRel metrics (time-to-activation, doc quality), the more defensible value now sits at the top of the funnel — being remembered, trusted, and distinct enough to make it into consideration at all. - Practical next step for readers running DevRel or community programs: audit whether your content calendar is quota-driven or outcome-driven, and consider carving out explicit "folly" time or budget for at least one genuinely useful, product-unrelated piece of content as a low-risk test of the cornerstone-content thesis this episode describes. ## 🔄 Refactor Appendix — devrelshow episode 52 - Joel Hans from ngrok ### 📚 Literature Atoms (H3) #### DevRel value has shifted from activation to top-of-funnel awareness > [!quote] ID:rw_pending > it feels like oh my god onboarding be damned like I just need to get people in the funnel **Context & use**: - Mid-episode, discussing why AI-assisted development and abundant competitor choice have changed what DevRel optimizes for. - Central thesis of the whole conversation; anchors the brand-marketing reframing of DevRel that both hosts converge on. **Tags**: #xref **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### Fixed content quotas are named as a direct cause of DevRel burnout > [!quote] ID:rw_pending > forcing dev realm people to produce like x number of pieces of content every week or month like whatever the like holding people to a calendar I feel like it's really dangerous because it like it leads us to burnout **Context & use**: - Joel describing how he manages his 3-person team and what he's negotiated with leadership. - Directly actionable for any DevRel/content lead evaluating their own team's cadence expectations. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> #### Sanctioned, unmeasured "folly" projects are reframed via Disney's Disneyland gamble > [!quote] ID:rw_pending > Walt Disney the person he had this folly which was Disneyland and it was this like ridiculous idea that was wildly expensive **Context & use**: - Joel explaining why he replaced "side quest" framing with "folly" when describing protected speculative work time. - Useful analogy for pitching leadership on unmeasured exploratory work. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://pending) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### DevRel autonomy requires leadership trust, not just budget **Claim** (one sentence, Courtney's voice): Experimentation-friendly DevRel work — cornerstone content, unmeasured "folly" projects, resisting quota pressure — only survives when leadership already trusts the practitioner's judgment, which means the real prerequisite for this strategy is a trust relationship, not a budget line. **Evidence pointer**: [[#Fixed content quotas are named as a direct cause of DevRel burnout]] **Scope & conditions**: Holds in orgs where DevRel has an executive sponsor willing to defend unmeasured work; breaks down in orgs that only fund what's immediately attributable to pipeline, or where the sponsoring executive turns over. **Links**: - [[courtneyr_work_logging]] — because applies-in ongoing work-logging/loop-engineering discipline that similarly depends on sponsor trust rather than rigid metrics - [[Content Strategy 2026]] — because extends the cornerstone-content thesis already active in Courtney's own content planning <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Compare ngrok's "Little Internet" pedagogy approach against Courtney's own /explainer video pipeline — both use hands-on, protocol-level teaching as brand-safe content. #xref - [F2] Research whether AI coding agent training data measurably predicts which infrastructure tools get recommended — testable via H4 in Hypotheses. #articleseed ### → Things 3 (max 2 actions) - [ ] Skim github.com/ngrok/little-internet for a possible Airo AI Builder or explainer-video angle on "teaching fundamentals through a hands-on physical demo" — content-strategy #things <!-- deep-read:sections end --> ## 📺 Video  --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=uQ4KmED0Mlg)* **[00:01]** [music] Heat. Heat. [music] [music] >> [music] **[00:32]** >> Hello. Hello lovely people. Welcome to another episode of the Devro Show. Every time, every time, you know, 15 minutes before the show, I book the time with the guest and we just go about like some house rule about to be sure how the live stream is going to go. And every every time I'm like, "Yeah, I really need to lower down the volume of the intro, but like I need to redo the video." And every time I forget, but at the same time, every time the video is playing, I'm just like, I love the sound. Like I'm just it just pump me up to start the **[01:03]** show. I love the music. It gives you energy. So like maybe I will just stop to try to think about the fact that like one day I should probably lower the volume uh and just keep it like that. But uh also really excited because you know uh conference season is uh at held. It's summertime which mean that I'm at home a little more a lot more than I'm used to. Uh which also mean that I can do uh that live stream a little more frequently. So um for those of you that may not have know I changed the formula **[01:33]** a little bit not the formula of the show but like uh the initial thought was like uh you know previous work previous job. Uh I was doing the Devrell show but it was a smaller company. I was doing less conferences. So I was doing a live stream with my employer every other week. So I was like, you know, the week that I'm not doing the live stream of cube first, I'm going to do the dev show. So I was trying to do the devil show every other week. But when I changed up, started to travel again and I tried to keep like every other week within my schedule, but because of the trips, I was not able to do that many **[02:04]** shows. So now I'm trying to do one every week when I'm available, which is not every week, but that also gave me the opportunity to do more shows because I have a lot of people in my weight list. Joel, I can't remember uh when we started to think about you coming on the show. Probably a year ago. >> Probably a year. I I that would be my guess. Maybe even more. And and yeah, I think you uh you know, we both have with our work, it's like there's there's seasons of work, right? where you're like focused on one thing and then you're focused on another thing. So, uh **[02:36]** you know, it's taken some time, but very happy to be here and just to chat with you. It's been it's been a number of years since we've since we've chatted. So, uh looking forward to it. >> That is true. So, thanks for being a guest. Also, thanks for uh being patient with that, but hopefully I'm going to be able to get uh the other guest on the wait list a little bit faster. there's still a long wait list so that may take time but at least uh that's going to go faster with that kind of like new formula but again uh how is life >> life is good um yeah so I mean I could **[03:08]** you know like I could talk very freely and openly about all the all the things but you know this being a Devril show and uh probably people are probably most curious about what I do for work and what Devril means to enro um which is maybe not what I expected or what other people would expect. Um, so yeah, my name's Joel Hans. I've been at Enro for two years now. I think probably like almost two years, like a a year and 11 **[03:39]** months and two weeks or something. It's very close to that anniversary. Um, but I was also before I joined Enro full-time, I was um I was a like freelance writer. Um, and that was where Fred, you and I interacted uh with a previous uh, you know, previous company you were at and I was freelancing for them as well. Um, but then Enro kind of convinced me to go to the dark side and become a, you know, full-time employee again and and here I am two years later. Um, doing very very different stuff than **[04:11]** I was back then. Uh but but loving the challenge, loving the diversity of things in front of me and um yeah, having having a good time. >> Yeah. I mean um I have a I have a weird memory, but like it was at Cube Shop if I remember. Yeah. It's just because you know the the the last job I had, I went to three companies with exactly the same role. Meaning that like when they hire me as a developer advocate, uh it was the product cube first. That was a companyish that was acquired by cube **[04:41]** shop. So it was kind of like a project from cube shop right >> but after that they got acquired by Civo but they they they kept them dependent so we were like cube first and we started to work on a second project so we decided to rebrand so we become from cube first we became uh construct and uh after that construct was totally absorbed into SIBO but like I was uh being let go like just before uh before that but so I had like three company names within in a year and a half, two **[05:13]** years, not even two years. >> Like what, you know, what are you why are you hopping around so much? And it's like, it wasn't me, it was, you know, they they're changing it under under my feet. Um, exactly. Honestly, like the biggest I don't think this is any like news or or like a novel thought, but I think that the the biggest challenge of Devril uh if you you know like however you think of that that word because everyone again has different practical you know ways that they're doing it. It's that like you like the ground is **[05:45]** always shifting under your feet and you have to always be I don't know you have to be adaptable or agile or something because you don't know that like one quarter you're asked to do a certain kind type of work the next quarter it's a different type of work the next quarter they you know the company gets rid of everybody and you've got to go kind of like find your feet again. Um, and I it feels it feels unique in in our world compared to the the people that I interact with a lot like in the companies. Um, it feels like we have a **[06:15]** we have like a extra stability problem that we have to we have to constantly navigate. >> It is. It is. And and and it's one thing that I like and I don't like about the role. Like the fact that like there's so many things you can do within that role is something that I like. I have ADHD. I get bored really easily. So if my job was always doing the exact same thing all the time every day, I would get bored out of my mind and I would not do that kind of job. So I love that call versatility of the role in terms of **[06:46]** like yeah you it's basically 10 20 jobs in one because you you you need to have expertise or good enough in like as a like depending on the role like like you're either a technical writer or a technical support or support engineers or engineers developer or social media manager or community manager a public speaker or like like there is so many of those like role that you put together and it depends on the But um it's also the part that I do not like and I say that often people if you've joined the show before you hear **[07:16]** me I'm old I'm repeating myself but like you know when when you're an engineer developer and you look for another job as an engineer developer the job is always the same what's different is like you're [clears throat] going to work on a different product with different technologies maybe different practices best practices or tools but at the end of the day you are building software now it may be different with AI but like at the end of the day you still like the end results of what you do a software. So it's clear like you're looking for an engineering job no matter where you go. It's just the tools and the the programming language or libraries you're **[07:48]** going to use that that's going to be different. But with developer relation it can mean so many things. So many things. So it's al why it's why I like when you said like um when you talk about the fact that like yeah it can be different uh depending on the role and it was also different like when GR approached you and it was different from what you taught. So, um, let's talk a little bit about this. Uh, what does that mean? Like, you started as a, uh, by the way, I need to say that before I forgot, you you were probably still an amazing writer. Um, I was really **[08:22]** >> not super open working with an external technical writer when I joined the company because I've had bad experiences and, um, usually and and there there's a lot of good uh, people in company doing that. I was just talking with a friend of at Hackmebo recently. I love their work. They're doing great. that most of the people are not doing great. Uh but you were you were amazing. So um I really liked working with you. So I just had to say that. Uh I know I know I'm cheesy but uh it when it's due, it's due. And I uh I like to to say those **[08:52]** kind of things uh when appreciate that. >> Yeah, it's due. >> Uh with that said though, you switch from you purely uh writer's role to uh you know developer relation. Actually your first role I'm looking at your LinkedIn right now. You started as a senior developer educator. >> What does that what does that mean? What what was your job when you started at Enro? >> I mean I think that's like that's in indicative of the whole like Devril can be so many different things to different people because yeah we didn't like at **[09:22]** the time there was there was other people in the company that had more like developer advocate role like the the sort of like kind of titles and and scope that you would expect. um and they were doing more like conferences and uh you know all like that side of things and and I was brought on to be more I'm trying to think back it's like been two years now it feels like a feels like two decades ago but um but yeah mostly to be like what I like one of the roles that I **[09:54]** think is really cool in Devril and and what I was trying to do at the time was like you you really try to be the expert in the product of anyone of all the customers of all the engineers of even the CEO like you are the person that you could get on maybe maybe with the exception of like uh support engineers or or customer engineers who really have to be like in the weeds of implementation but you kind of take on that role of I'm going to go deep into this thing and I'm going to be an expert and I'm going to share what I've learned **[10:25]** about it uh with with other folks. So I my first kind of like success at Enro was writing about Enro has this uh this configuration let's say a configuration language uh called traffic policy that lets you manipulate traffic as it's passing through Enro uh when when Enro's operating as as your gateway between the public internet and you know the services that you have running. Um, and I wrote a like 10 things that you didn't think you could do with traffic policy. **[10:57]** And even the engineers who built it were like, I didn't realize that you could manipulate it in that way. Um, and and that was really fun. And that kind of set me off on that. Like for a while it was like, yeah, I'm going to be the expert in this thing and I'm going to mostly produce written content. But I ended up doing some, we were talking before like some live streams where I was doing demos. I was I started you know recording video trying to like product marketing around new features or new products. Um so it it really kind of **[11:27]** the first like six months to a year really um was really like in that mode. Um and then in the second year it's really changed to to be something quite different to the point where like I honestly I'm like I'm not really a dev rail person anymore. like we do some Devril things, but it's like the ven diagram is kind of like it's diverging in an interesting way. So, um I'm happy to, you know, continue to ramble about the story. Uh, but you know, like >> I I'm cur I'm kind of I'm also kind of **[11:58]** curious of like >> where do like the people that you talk to and that you you have on this show like do other people feel as though the Dev Rail role is is changing in a way that is unique or like we haven't seen in the past couple of years? Like I feel like it's fundamentally different now than it was five years ago and like the the seismic change is bigger than it than it used to be. I mean it depend on the guest. Um some people had that feeling. Um I have the feeling that like it changed **[12:31]** a little bit. Uh but I would be curious to understand like what you mean that like like fundamental fundamental change. Um because for me >> the role is still the same that it was when I started 14 years ago is to I want to help developer being successful. My job is to give love to developer, which I love when I say that at conferences and everybody's afraid. I'm like, "No, I'm not going to kiss you." Uh, it's just it's just my way of doing things. But like I like that role for me is being like that friendly, social, **[13:01]** technical, approachable face of the company. And I hope you're going to be successful in my product, but at the end of the day, it doesn't matter that much because I'm building connection with developers. How I do it may have changed a little bit, but like at the end of the day, that's like that was always my goal. like I I connect with developer I you know evangelize and things this is also why my first title was technical evangelist developer evangelist I can't remember but also I represent developer internally so I bring the feedback to the product team I quote unquote defend **[13:31]** the developer audience for the rest of the business that may not have the same expertise or the same approach to developer that could maybe sometimes ruin what I'm trying to say or what I'm trying to do or what I'm trying to build but um also So maybe I'm I don't know maybe I'm I'm too much into my old way of thinkings about what is de that I don't see like the kind of like change that may happen in the rest of the industry. There's definitely a change happening because of AI and maybe I'm naive but like when I think about that I **[14:02]** feel like uh and again also maybe I'm preaching for my own stuff but like I feel like Devril is is even more important right now because we're still removing we're still heading one layer uh away from the human with AI at different ways of doing businesses and I I feel like the the human human needs to connect with human and I know it's not scalable all the But I also think your role is a bit more important in that AI era. Anyway, I'm blabbering now. Um >> I think I think that's that's like yeah **[14:33]** is is kind of kind of what I've been seeing too is that like even the stuff that I experienced within Enro is like it's it's not purely driven by AI transformation or anything. I but I but I do think as what you were just saying as part of that is like people people want like a friendly familiar face to interact with or like you get a newsletter from the same person every month and you're like oh yeah like Fred and you know like their names like your name gets associated with the brand like **[15:04]** with the company and so that's what I found at MRO is that like Devril has ended up pointing a lot more more it looks a lot more like brand marketing than it because the like technical like recording a a demo of how to use a product or um or even giving talks about uh like a certain feature of the product or anything like that. Um it's it's a lot more like what I think is really important now is that yeah people want to feel like they're talking to somebody **[15:35]** and and I think like AI can produce a lot of stuff but we need we need smart people with good taste and have a high bar for quality to to filter that through or to you know to to rev on it and to to make it better. And so I feel like that's where PE that's where it's like Devril can differentiate itself from others is by being like we understand that we could produce like a million blog posts tomorrow about every nuance of our product but we're going to **[16:07]** intentionally approach it in a way that like shows that we care about our product. We care about the developer experience or we care about you know making this uh like just giving you a good feeling while you're interacting with us. Um so so yeah it's it's it's really changed to be a lot more of that like and enro has a sort of unique problem in that we >> we get people when people think of enrock people who have heard of it um they think of the mrock from gosh I **[16:40]** don't know like 10 years ago 5 to 10 years ago which is like oh yeah it's that tool that lets me uh like create a tunnel into localhost and I can share that with my friend Um and and while that is still true, like that is still where we get the majority of our signups every single day is people wanting to do things like that. Um now it's also changed to be more like people wanting to do agentic work and connect agents across network boundaries and all that **[17:10]** kind of stuff. Um but we have this thing where we we're trying to like change the perception of what Enrock is that it's production developer infrastructure. you can you can run your services behind it in production. It's like it's a fullyfledged API gateway. We have DOS protection. We have a WFT. We have all of these things that you need. Um and and so that's where the brand stuff becomes really important. It's not so much teaching them like how to use the product. Like that's a that's a problem that we can we need to solve for later. **[17:41]** the problem right now is getting people to perceive us in the way that um that we that like matches the reality of the product today. So, it's a it's a really unique version of Devril. I think maybe it's more common than I know. Um but it but it feels like it's an unexpected swerve for me. >> I I think now understand more. I I think it really depends. Um I don't know if it's like a general industry uh change. I mean, I only have one job. I do not know what's happening everywhere. Uh but **[18:12]** I I feel like what you describe from my experience and I may be wrong. It it really I think it depends on the company and what's the needs of the company. And I think all those things are are valid. Like if your job is to generate technical content and it's mostly the only thing you do it's valid like you need people to be able to do that. If it's your devril job it's fine. Uh you still connect with developer you still help them being successful. So from my point of view it's the job. If your job is to do a little more what you describe, it's fine too. It's still dev. You still can't connect with developers. Um **[18:42]** >> yeah. >> Yeah. So I take really depend like right now uh as an example I do a I'm a little bit in between uh of of you know the the what you describe a more traditional way of doing Deborah which is like okay I need to like do videos about those features and editing but also I need to you know be be the voice and connect with people and and and be the the person that people recognize also trying to change the perception or change like make people understand that like hey it's not the same rock that it was 10 years ago like at Tiny MC Um I still create **[19:14]** technical content not as much as I would like to because um we have a need especially on videos like I want to create more video technical videos um because I think there is a need for that and I don't think we have enough to um >> you know um be sure that developer have what they need to be successful with the product but at the same time I think the biggest work I have to do is um first just establishing myself as like the the face of tiny MC someone used to do my job before. Now I'm here. Okay. I've **[19:44]** been here for a year. Uh it's it's more in place, but I still have work to do. But we have something a little bit similar about what you described. Uh Tiny MC uh whether you know it or not exists for more than 20 years. And usually um people use tiny MC at some point. It was prior to let's say prior to WordPress moving to their uh what they call the Gutenberg uh you know way of of writing blog post. They were using TMC. Uh it's used in Moodle. It was used in Braco was used in multiple places. People used it in the past maybe 10 15 **[20:17]** years ago and they have the impression that like oh yeah it's just it's just a whole software. I'm like no we we we rebuilt things we update our best practices. We use like latest technologies we improve security. We improve stability. We improve accessibility. It's not a product. Even it's sensibly it's still a rich tax editor. We didn't change like our mission. We help people create rich text content but people kept the assumption that like no it's like it's like you're not part of the cool kids anymore. So a big and people I I don't know what **[20:48]** happened with all respect for people in the team at some point I think we dropped the ball and and we stopped being out there with developers. So now there's a lot of people when I go conference like oh TMC is still a thing. I'm like oh yeah like profitable business is going well. >> Yeah. >> But they were like oh I didn't know you were still there. You you still exist. So all that to say a big chunk of my job right now is back to the basic of like creating awareness like just telling people that like first we exist we're still there we're kicking ass great product give it a try try it uh but even **[21:21]** that like quite often I don't even talk about my product I'm just like sharing like cool stuff for developers that are unrelated to my product because you know uh product pitches nobody likes that or mostly nobody likes that especially developers so I'm just here to talk about it stuff that helps you to be successful. But I'm still Fred from Tiny MC. So hopefully you're gonna be curious enough to like look at it and like maybe try it and maybe become a user slash a customer. So >> yeah, I mean it honestly sounds it it sounds like it's you know part of the same the same problem space that I'm **[21:52]** dealing with and apparently I have I have a delivery here uh outside. Um I you need to go pick the package. >> Is going to go nuts uh in in a second. Hopefully hopefully no one will be able to hear that. Um, >> that is not a problem at all. >> Yeah, I mean I do think that I do think that it's it's very true these days where where the sort of like tech hype cycle is so fast and new tools are coming out all the time, new competitors like I I you know I have like social media monitoring tools for Enro. Um, and **[22:25]** I think now literally every day I see someone on HackerNews or on Twitter or uh uh like what's the on Reddit and they're like I I made a Enro alternative that you can self-host and you can you know like it's such a it's such a thing now that that I really do think that like awareness as you said is is so important because as people are using coding agents to build stuff really fast and like if you're not even in their **[22:55]** brain uh like as as an option like they don't even think of tiny MCE as an option. They're not going to tell their agent to build it. They're just going to rely on whatever it says. Um and they will completely ignore the idea of like uh you know investigating all the options and and doing a deep dive and everything. So it really really feels that like you know Devril I feel like has this is kind of what I what I think of when it's like the change is like feel like Devril was has always been like a big chunk of it was like you're **[23:28]** spending time on like onboarding you're spending time in the documentation to make the experience better and make it really smooth like the time to activation or the time to like the aha moment with the product was like that was held as the top like you know like the key metric for dev rail teams if you could reduce that by x% then you're doing a great job and now it feels like oh my god onboarding be damned like I just need to get people in the funnel I need to get them [laughter] using it um **[24:00]** because there's so much there's so many other options there so they're wealthy people are you know developers are wealthy for choice um so so that's I mean that's been a again like an interesting it's like okay well how do you do how do you grow awareness in a way that feels unique and differentiated and and stands out again among the there's so many people producing content. It's like how do you make yours interesting? So, we've we've like I've been very fortunate to be able to bring on a team of uh of developer educators **[24:33]** into this like developer education team. And we're we're trying to do some some weird stuff. We're taking we're taking risks. for writing. Uh Sam Rose, who's who's one of uh one of the people on the team, a just phenomenal uh writer, um wrote like a 7,000word blog post about quantization and what like how quantization works in LLMs to like reduce the size, if you will, of LLMs. um and and make them you know something **[25:05]** that we can we can you know we can run on our local machines or like it's scalable to run on the vast server farms that you know OpenAI and Enthropic and all the others are are using and and then just hoping that someone will read one of these things just purely for the sake of learning something that has nothing to do with Enro um and then they're like oh yeah Enro like I remember reading that thing like maybe I should check them out again and like maybe I should consider them. Y **[25:35]** >> um >> it's a it it's a it feels like a big risk, but I'm and I and I don't know 100% if it's going to pay off in the way that we want it to, but we sure are having fun while we're doing it. And I feel like that means a lot um in our role, right? like just having fun experimenting, building stuff, >> remembering that we all have this like >> in innate like we want to cobble stuff together and see it live and share it with people. And the more that we can do of that, I feel like the better off our **[26:06]** we all are as as Devril people. >> There is so many things to unpack and what you said and uh I don't know if it's been there for a long time. I don't know if you have it as a guest, but I just noticed there's like a notes tab now uh in StreamYard, and it's pretty there since forever. So, now I decided to take notes, which was a mistake because usually I don't. So, I only remember I have ADHD, so like my I only remember the last thing the guest talked about. So, I don't have 10 ideas to follow through, but I did the mistake to take a lot of notes with you because **[26:37]** everything was like, "Oh, I want to talk about this, but I'm not going to cut him. I want to talk about it." And now I have so many things to say, so maybe not in the future. No, actually that was that was interesting. It's also the reason why I have so many things to say. Um the last notes I took was about you know taking risk and having fun. Um I can't agree more with all that. Um and people will say like yeah it's a job like or or I don't know like the leadership team like hey it's a job we pay you not to have fun. We pay you to to do the outcomes. But uh I firmly **[27:09]** believe that like hopefully most people should have a little bit of fun at work. I mean it's work. we have to do it because we need money. Nobody is like yeah or actually it's not true. Some people wake up in the morning they're super excited to go to work because that's their life. I'm not like that for me. I love my job but at the same time I do it because I need money. But especially in a role like that I always say like you need to be excited about your product or you know you can be excited about your product if you start a new job. But it also the having fun part is also it translate to the users or the people or the customers or the **[27:39]** developers that will see your content that will sell you at events. If you're like you're bored out of your mind, if you look like you're being forced to do things that won't show well for the company, that won't you it will be harder to create connection. So I think that the having fun part >> as much as again I seems like I'm preaching for my own things. I'm getting paid to have fun, but at the same time, yeah, of course I need to have outcomes and stuff like that, but like I think it's important, but taking risks is something that like I think we lost a little bit with Devril. Uh because Devil **[28:12]** It started before I started to do that role but not that long before but it was like yes we had goal especially because my first job was at Microsoft so you know everything was KPI and everything but at the same time it was more about let's do what needs to be done right now and what makes sense to be done right now and hopefully that's going to be fruitful. Um, but you never know. And and and the problem I see in some companies that we're so tight with like those are the goals that we need to achieve and I need to write 10 blog post this year and I need to do four events **[28:43]** this year and that now we don't have like space anymore to like hey there's an opportunity right now to do something. there's an opportunity to write a 7,000 words article about uh quantis quant I don't know how to say that word in English quantization from the ground up uh article because this is something that I think is cool this is something that I think will uh resonate with my target audience it's not about the product but it's what I call that Trojan horse content as you said people will come on the blog on the blog they will read about it like oh that's **[29:14]** amazing and uh they were like oh what the heck is encro let's say they don't know it and they go look at it and maybe they don't need it right now. But that's another thing that is really hard to reconulate with reconulate with the rest of the business because how we do business it's fast. We need like to have the return on investment fast. We need to make money fast. We need to see more user fast. But developer relation yes we can have quick win. But from my point of view was always about medium to long-term impact. Meaning that like that blog post may not have brought customer right now or users right now. But as you **[29:46]** said, maybe in two three months that person will like, hey, I need to do X and like, oh, I remember and Grock is is doing what I need and like, oh, they wrote that really nice article and and that article that was unrelated to the product brought them back two, three months after when they needed what you're selling or what you're offering or they change job or they change project. So I think it's it's it's important. So feeding the top of the funnel as you said I think it's a little bit if we do our job well that's the **[30:16]** positive side effect like we're going to feed the top of the funnel but it may not happen right now it may takes time for that to happen >> because it's about the people it's about humans it's about building relationship so but it's it's quite often hard to >> fit that within the structure of like how we do business in this >> yeah it's like oh yeah we need you know we need results we you have KPIs to hit um I I don't I have like two pretty strong thoughts about Devril and in my so I've been leading this like **[30:48]** this team for a year and change and and now we're up to three people which is not by any means a massive team. You know, I'm sure you've had people on here that have larger teams than that, but I think that the the first thing is like forcing Devril people to produce like x number of pieces of content every week or month like whatever the like holding people to a calendar I feel like is really dangerous because it like it leads us to burnout. It leads us to producing like subpar content for the **[31:19]** sake of just like I have to hit this deadline, right? Um, so I've I've really tried to, you know, like orchestrate this team and and talk to leadership and and like kind of have this negotiation of like as you were saying, it's like the long-term benefit is going to pay off here. Like the long tale is better than like forcing Sam Rose or someone else to like just keep churning away at more stuff. Um, so so that's one of the the principles. And then I used to when I **[31:50]** when I would like interview people for for roles that I was hiring, I used to ask them like what side quests they would want to go on in their job. Like the fun thing that it's like, you know, because goo like I don't know like companies like Google, they used to have things where you get to like every Friday you get to work on your personal project, whatever. Um and then I so I I used to frame it as like a side quest. Um, which I think in hindsight made it feel like it was more work for you. So, it's like, **[32:20]** >> oh, >> you have your normal job, but then you have your side quest that you have to like add more hours on. And, and then I was listening to a um I was listening to this like fivehour podcast about >> the Disney Corporation and like from the very beginning of the 1920s and there's this phrase that they it was like Disney's folly. So, like Walt Disney, the person, he had this folly, which was Disneyland, and it was this like ridiculous idea that was wildly expensive. Um, and and stole a bunch of **[32:51]** time and money away. Um, but it was like this huge risk and and the company gave him the time and space in which to take this massive risk and they didn't know if it was going to pay off or not. And clearly, it it has, right? you know, like now Disney is the massive conglomerate that it is. And so I'm like I I kind of like I want people to have follyies. Like I want them to have these things that get to absorb some of their time that would normally be spent on **[33:22]** that like, oh, I have to produce these things all the time. And it it might fail spectacularly, >> but at least we're trying big things and we're enjoying the process. And so if it's if it fails then it's like well I had fun doing it and you know like it was it was a good experience for me a good learning experience. Um >> this is the thing though. I mean like even if you fail um I'm not a big believer that like oh there's a reason for everything in life and blah blah blah but at the same time um there's **[33:52]** always I think at least a learning you learn something maybe not in a personal life it should happen like this [ __ ] happened but like at work you try a project it didn't work okay take take the time to understand what didn't work like did did we focus on the round thing was the execution not not about blaming was it like that was really nice but like it did not like I don't know it did not work with your target audience like no no no matter what but it al it's it also helps you to bring you to the next thing and hopefully based on what you **[34:24]** learn the next thing is going to be a little bit better or are you going to fail faster if it doesn't work uh because we have a tendency also to you know try like always do the things that like everybody's doing and that's fine but like as a business your goal unfortunately for the better or worse is to make more money. Uh, and to do that you need to innovate. You need to try new things. You need to try new approach. You need to target new audiences. You need to and it's impossible to do that when you have like a full calendar of like, oh no, I need **[34:54]** to do all those things and I have no space to I have no space to breathe or I have no space to just go crazy and brainstorm and thinks about something. So, I really don't have time to do something else. So, I can understand why especially like the side quest. I can understand also why people are like, "Yeah, no thank you, but no tanks." [laughter] >> Yeah. >> But yeah, having actual time dedicated in your, you know, in your amongst everything else to to actually, you know, dig into this stuff. Like I feel like that's um that's that's super super **[35:26]** important. Yeah, we we learn better when we when we're having fun along the way. Um and and so we're we're trying to to trying to live that ethos as much as we can. Um, you know, again, whether or not it's successful in the end is sometime, you know, some of it's yet to be seen. Um, but you know, at least you know, at least I'll be able to say like I tried something here and and you know, take or leave what happened, but at least I I tried to, as you said, like innovate because I think that's that's probably the thing that I was I was just talking **[35:56]** to my uh my boss earlier today and I mentioned like an omen, like a dark cloud that kind of is like hovering and I think about and I think that's the biggest one is like am I doing things in a unique way? um that that like stands out uh and whether that's you know whatever the devril task is there it's like am I doing it you in a unique way um but it's so hard to do as you said if you don't have the breathing room to do the like create the deep creative thought to get there >> and and uh we've been talking for a **[36:27]** while usually I would say like hey that's time to move to demo but I have one last question about that because uh first I really want to know the answer secondly uh I think that could be beneficial for other uh and if you don't want to share about it that's fine too but um how were you able to bring that like way of thinking to enro because I do not I know in Grock as a product I do not know it as a company I don't know I know a couple people working there but like I don't know the culture like at many places where I've worked it would be really **[36:59]** hard as much as I would like to and I think I I would have like the being able to show the benefits of that it still doesn't fit within like you know like like a square fitting in the Rono uh at the business level because you know we need to measure thing and we need to have KPIs and metrics and we need to do this this this and we need to measure how many new users we get out of it and all those things. So it's it's a like devell is already I don't know if I'm dev is already a hard cell most of the time uh because it's a little bit harder to measure depending on what we do and **[37:30]** now we on top of that you're like hey also want to try to innovate and I may fail spectacularly but maybe I'm going to be successful or I just need time to do things that are not part of the spreadsheet that we measure like if you want to share about how was it received how do to sell the idea. Was it just part of the culture and and and your boss was like, "Fuck yeah." Like, "I was waiting for someone to do something like that." >> That's Yeah, it's like trying to peel back the lineage of it. I think as much **[38:01]** as I would like to claim, you know, credit for having established this culture and and, you know, done all this work myself. I think it really I think I've really been fortunate that leadership has been like very on board the idea if not having generated the idea like looking at the landscape of the business and the problems they had in front of them like the the brand side of things was like that that percolated up aside from like alongside like product **[38:31]** usability things and the fact that we don't you know there was like a couple of big problems that they surfaced and that was one of them. So, it's like as much as I would like to say that I like pitched them this idea and they were like, "Oh my god, what a brilliant idea, um I think it's just been more than anything like trying to like trying to lead by example myself and then um my my boss uh the the the chief revenue officer like she has been enormously helpful in like trying to get the people **[39:04]** like you like I try to lead the way and then we get other people in to join the team to kind of like follow and add on to that and then like more someone else wants to come and do the same thing and we've kind of been like it's like a a snowball that's rolling. Um, and I feel like at this point we've really we've really gotten to the point where we like understand what we're trying to do and we have the evidence that like we can pull all these metrics of, you know, the these blog posts and what they've drawn and the impressions and and the the **[39:34]** comments and everything like that. Um, and we can't say that x number of people signed up because of that, but we can say that every every impression or every time someone reads one of these blog posts, we're doing that work of changing perception and we're doing that work of making them maybe consider us. Um, and and the evidence that we get that I can continue to use to to sell that story and say like, "Hey, we need to keep doing this is that every once in a while we'll get a comment on Hacker News or **[40:04]** Reddit or something and they'll say like, uh, I I just heard about Enro and I don't know much about them, but they they write cool blog posts, so maybe I'll like I'll go and research them a little bit more." And it's like, great, the process is working. like we are we are slowly but surely changing the hearts and minds of of developers. Um and and yeah, if we can at least, you know, try to try to move that a little bit, then it's a su a success and we'll we'll keep doing it until, you know, I **[40:36]** don't know, until I'm told that the time is up. Keep having fun. >> I like that. I like that. and and um we're going to move to uh the second part because we could probably take uh talk forever um about interesting topic though but like yeah um the stream is already long so let's move uh to the demo but before that >> I just want to leave with with one thing that may like not everybody may agree with that and it's not me trying to be off the hook but um about you know that **[41:07]** having that space to be able to to innovate and try new things where was the most impactful at every jobs I had. I had too many jobs for my own good as a developer advocate. Where at the companies where I had no fixed goals or KPI, they [clears throat] were just like you're developer advocate do developer relation things and do whatever you need to do to obviously help the company being successful. And I was basically deciding what I think was **[41:39]** the most impactful. And like at one point it was like okay uh we need more video content. let's start a live stream. And at some point I was like, hey, we do not know what our users want. We need a community. Build a community. And at some point I was like, hey, we are open source company. We have no proper contribute document or or or like practices about people that will at some point do pull requests. I was like, I think we need that to like show the example and and be a good open source player. And every time I was like, I **[42:14]** think this is what I need to do. I had to do it. And at some point I was like, hey, you know what? I do not know that part of the product. I'm going to disappear for two days. I'm going to learn about this. I'm going to come back. I'm going to be able to do other stuff with that. And and first the the the and maybe that sounds like like crazy talk for most people because everybody have goals and KPIs, but like I don't think I was doing nothing. And as I said, I think I was even more productive and have a bigger impact because I didn't have that pressure of like, oh yeah, I said at the beginning **[42:44]** of the year that I had to write six blog posts or I don't know, I had to um reach out to like had that many uh readers for no matter the number of blog posts I do and now I need to focus on that versus like there's something more exciting that would be more impactful or something that is just more enjoyable to do right now or something something happened in the industry. You know, a small example that I really love uh and after that I shut up. Um you know that that all we talked about it in the last live stream but like uh Sony with PlayStation that went like hey we won't **[43:15]** do any physical disc anymore and people went crazy about it for different reason. I want to to talk about it again. My last guest was was pumping up and it was like that's crazy. But uh GitHub like the day after they were like, "Hey, we still believe in physical disc. If you want a copy of your GitHub repo, just submit the form." And I don't know the first 100 people. And it's it's stupid in a way that like >> it's just like a cool gadget to have like do you really need your like code on your repo to be burned like on a CD **[43:48]** and have it ship? But like they were like surfing the wave of like this is what everybody's talking about right now. At least everybody in the gaming industry even to people outside of the gaming industry. We're just going to have fun. In that case that cost a little bit of money because they had to burn CD and ship them. At the end of the day I was like even if I don't want that even if I don't need that like that was a cool even if there is no educational around it like the team and and maybe it was not devil led but like my point was like the team has the **[44:20]** >> freedom to be able like let's ride that wave because that's going to be a cool thing and like people talked about it even people that were like that's stupid why should I do that they still talked about it and from my point of view that was brilliant but you need to give the freedom to people to be able to do those things if they're stuck to the neck with goals and KPIs. It's it's >> Absolutely. Yeah. There's something about like trusting like Devril operates best when it's in a high trust environment. Like I trust you to to make the right call about what **[44:50]** could have the most impact and and yeah, just go out and go out and do it. And it's if you don't have the trust, then it's hard. I think that's where a lot of Devril kind of like falls apart is that it's not the trust isn't quite there. Um, and it's hard to build, but you know, it's it's something that we all we all got to consider and continue to to work against. It's that that part's not going away. >> Yep. I agree. With that said, demo time. Uh, which I'm really curious to uh learn more about because when I ask uh the **[45:21]** guest like, "Hey, give send me one sentence. You can demo basically anything you want." Yeah. >> Product related from your employer, project you do on your phone for fun, whatever. And they were like, "Hey, I build an internet functioning internet on piece of wood in my garage or I don't remember exactly, but I was like, please, actually, please don't tell me more because I want to demo and I don't want to learn about it before you demo, but I was like, please do that demo." >> So, >> yeah. >> What is it? What What are you doing, **[45:51]** man? >> I I I we were just talking. I don't think I can show it without like messing up my camera, destroying everything. Really, which really upsets me. Um, but I'll have a I have a video that I can share really quickly. Um, yeah. So, the the idea was that like I I I feel as though I work at Enrock. I do Devril Enrock and like networking isn't like the only like it's not the only thing that we do. It's not like we're not doing the sort of like networking of uh **[46:21]** you know like data center like that level of stuff. But like networking is at the core of what we do. it's connectivity and and I'm like I kind of understand how the internet works, but there's a lot of pieces, you know, along the way that I don't understand at all. Um, and I and I have maybe tried over the years. Um, but none of it's sticky. Uh, where I like retained information and can use it. And I'm like, well, the internet's not going away anytime soon. You know, it's like **[46:52]** the most durable thing in the era of like the AI era. uh because it AI depends on the internet to work. Uh I was like okay well if I learn about the internet then that only makes me like it makes me smarter. It makes me a better devro person makes me a better um like you know better able to like empathize with these people um that are that are trying to deal with these problems. So so yeah I I bought a couple of Raspberry Pies. I bought some Ethernet cables. I bought like the stuff that you need to be able to wire these things together. **[47:24]** And um and I'll I'll share my screen and kind of like walk through my experience that I had. Um let's see here. I need to do a window. Um like the experience that I had when I first connected these things and was trying to understand >> like like I have two Raspberry Pies and I connect them together with an with an Ethernet cable. like, okay, they should start I should be like they should start chatting like I should be able to see **[47:54]** them communicating. Um, so I was like uh you know like but they're not like I can't I don't know what's going on. So I'm like okay let's look at the let's look at you know what's going on with the Ethernet like what's going on with the nick and I'm like okay there's nothing happening here. It's like the thing is down and I can do it on both of them. Uh, so this is just for context. This is me sshed into the two Raspberry Pies side by side. So I have one and two um just for you know the sake of of clarity **[48:25]** here. So it's like okay they're down. >> Yeah. >> Just quick question. Is it the uh little internet uh repo? Is it related to the repo uh little internet repo? >> This is that repo is where I'm like writing about these experiences. is I'm writing scripts that uh that you would be able to run to like replicate this behavior. Um even on like virtual like in VMs instead of if you don't have the hardware, I figure most people won't have the hardware. So they'll want to maybe learn stuff in a different way. So **[48:56]** this is kind of like why this is a a folly for me still is like I don't know the right learning meth like the right teaching method here. I'm learning stuff but I don't know how quite yet how to reflect that out. So then, so then what I do is I can I can plug the Ethernet cables in, which I just did. And then if I run these again, you can see that it changed like no carrier changed to broadcast uh and down changed to up. I'm like, cool. Okay, so like stuff is happening. Um uh but then I would maybe **[49:26]** also assume that I could like uh I could ping one from the other and it's like well that that doesn't work. uh nothing is happening and it's going to fail in a second here. Um so then it's like okay why is it failing like what's what's going on here? Why are they not able to communicate with each other? So so then actually it's sending many pings. So it's um getting kind of stuck here. So then what I started thinking it was like well can I can I capture all the packets **[49:58]** that are running between them and and start to try to diagnose this this issue like what's going on here. So what I'm going to do is I'll I'll unplug them again so that we can we can see what it looks like when you connect two devices together and like what what starts getting shared between them. So it's starting to capture and it should be good now. and I plug them back into each other and you can see there's like a flood of Ethernet frames here. Um, so **[50:28]** then I'm, you know, so I'm like trying to pick this apart. I'm like, what does all this mean? It's like, okay, I see ICMPv6. I see there's MDNS stuff going on. I'm like, and I see mentions of the two pies like here, you can see there's two MDNS frames where it's like pi fu 2 and pi 1. they they seem to be communicating with each other, right? And it's like, okay, cool. Like, but but why I still can't I still can't ping one from the other. **[50:59]** Like, that part still doesn't work. Um, so like, how are they at once communicating but also unable to communicate? Um, and you know, I spent a long time trying to figure out exactly why that was true. Um and and what I realized eventually is that you are seeing them communicate over IPv6, right? Instead of IPv4, um they IPv6 has a couple of protocols that lets neighbors basically find each **[51:32]** other automatically and start communicating. But but I'm not thinking like I don't think in IPv6 when I'm ping a UR like an IP address like this is what I want. I don't want the like super long uh IPv6 address and and I certainly don't want like a MAC address because that just doesn't work. Um so I'm like well how do I like like they're connected and they're they're like they're they're communicating but they're not like reaching each other in the way that I expect. Um, and that's **[52:03]** where I start to realize that it's like, oh, I should probably like stand up uh, you know, the the the like the nick properly um, and and assign IP addresses to them because there's no switch here or router. So, they're not getting stuff assigned automatically. And then it's like as soon as I Oh, it's gonna the demo is going to fail me here, isn't it? Uh, usually as soon as as they're connected, >> demo god's not with you. **[52:33]** >> Oh man, that's so disappointing. Um, you know, as soon as you assign the addresses uh to them, they can they're able to start communicating with each other. Of course, now I have 100% packet loss. Um, that's that's so disappointing. Um, did I pseudo both of them? I did. It was successfully added. Uh oh. Um yeah there >> um but yeah you can start to then like >> you can you know like okay so they're **[53:04]** connected to each other and like what is what is happening and you should be able to see a protocol called ARP um that and of course now it's not working um but you should be able to see this protocol called ARP that it's the address resolution protocol in which the two devices are negotiating they're who has Oh, there it is. Um, >> yes, >> it's actually working. So, it's like this is my device being like, these are the devices being like, I'm at this IP address. I'm at this IP address, **[53:35]** 1010.0.1, and here's my MAC address. And and it's going back and forth. Um, so both devices are kind of confirming with the other that they're like, I exist. Here's where I'm at. Here's how you can reach me. Um, and and this is usually the way that, okay, now it works. this is the way that these two devices are able to to like they're connected, they're reachable because they have identities. Um, and so I've I've kind of gone off the deep end and I've written a super long blog post about art because **[54:06]** I'm fascinated by it. Um, and there's so much more that I would love to like dig into. Um, but you know, trying to be respectful of the time here or or cognizant of it. Um, this is the kind of work that I'm super curious about right now and and and like again this kind of idea of a of a folly. It's like I'm spending time that I could be working on other stuff, but I'm doing this. I'm having a blast. I'm trying to share my experiences out and I'm hoping that for Enro it continues to like iter, you **[54:36]** know, reiterate for people that we're we're a company that's that's trying to teach you about these fundamental protocols of how the internet works and and hopefully that makes you want to consider the stuff that you know, everything else that we have going on. And I will share just like really really quickly so people can get a taste of um of what this hardware looks like. Um, I don't know if this if this works, if it's shared properly. Um, but what I also did was I I wired up these OLEDs um **[55:07]** so that you could you could track the state of the of like each device kind of has a cache of of the ARC states. Um, so it knows like this device knows that it can reach the other device at a certain IP address and then it goes stale and and then they reach each other again and there's this like life cycle to it. Um, and this idea of making it physical so you can like see it happening, um, I think is my my hope is that, uh, that makes it easier for other people to **[55:38]** understand and learn and, um, and and sort of start to piece these concepts together themselves. So, having a blast with it. Appreciate, you know, me getting through this. A little shaky, but we got there. Um, that's the kind of stuff that I'm that yeah, that that that makes me happy right now. And as much as I can, you know, put my elbows out and try to make space for this amongst everything else, I'm I'm going to keep doing it. >> No, no, no. That that looks like a fun project. And uh yeah, a demo wouldn't be a demo if you didn't have any cup. So **[56:08]** like that's part of that's part of it. Uh that that's a cool project too because as you said, like it's it's related to the business. Um, I don't know if you plan to do that because everything seems to be like nailed on the wood, but like that could be like a really cool talk you could do like at a conference about like how I decided to learn more about internet or come learn a little more about Raspberry Pi even if it's not and this is how I use them to do that and [clears throat] uh like there there is great content for developers that yeah you could take out **[56:40]** of it. So um maybe it's me doing >> job that are too business centric for the last couple of years but I always try to how can I maximize what I do >> uh to the next level. So you have that project that is cool and you have like that um GitHub repo. By the way, if people want to learn more and try to play with it, go on github.com on internet. >> Um >> yeah. Yeah, there's virtual scripts so that you can Yeah, like I said that it spins up VMs and so you could do it that way if you you know I assume most people **[57:10]** don't have ras a bunch of Raspberry Pies sitting around like I do. Um so go check it out. would love to would love to hear if anybody gave it a shot and learned something or got stuck or whatever and it's uh it's something I'm working actively on super open to feedback. >> Wonderful. And uh sorry I know I catch your comment a little bit late. Uh but you joined the stream late so I guess it aligns everything. Uh do not worry uh the recording is on YouTube. We really had a great discussion. You arrive around at the end of the discussion. You **[57:42]** missed the first part but the video is there. always nice to uh see you join us uh for the show. So on that note, Joel, I have the feeling that it brings us to the end of the show. So anything else you want to share with folks? >> Uh no, I'm I'm I'm feeling great. I really appreciate the the time to uh to chat about some of this stuff. I feel like it was a nice almost like therapeutic session of just getting to talk openly about some of these problems and some of these challenges and yeah **[58:13]** really makes me uh you know makes me be like I should do this more often with more of my peers elsewhere. Uh so really grateful for the the opportunity to come on and and and share a little bit of what I've been doing. >> Uh thanks uh thanks for being a guest. I always say it as much as my ego is big that show wouldn't be a good show if it was just me. It's all about the guests. You bring your ideas, your comments, your expertise, your question, your demo. Uh so thanks for being the guest. Thanks for uh everybody who join us live **[58:44]** and thanks for uh the people who will also watch the recording. And on that note, uh every time every show I forgot to take a note about who's going to be my next guest or one's going to be the next show. Uh but yeah, I'm going to be back for the uh episode 53, I think, of the show next week on the 16 next Thursday uh with Nicola Grani. Grani, I think. I think I'm No, Granny. Yeah, sorry. Uh Nicolola Grani is going to be my next guest. So, it's going to be 3 **[59:14]** p.m. on the 16th. I'll be back. And thanks to you, Anush. Thanks everyone. Have a great rest of the morning, afternoon, evening, night. and see you next week. >> All right. Thanks, ## Links - [[3. Resources/Permanent Notes/Education Is the Only Marketing That Works With Developers]] — DevRel earns attention through useful teaching and developer context. - [[3. Resources/MOCs/DevRel MOC]] — Practitioner interview retained as DevRel evidence.