DataTalks.Club Podcast Wiki

Wiki

Developer Relations

How DataTalks.Club podcast guests describe DevRel as technical education, demos, documentation, community feedback, open-source work, and adoption strategy for data and ML tools.

Related Wiki Pages

Open Source and Developer Relations Developer Experience Community Building Documentation Technical Writing

Definition and Scope

Developer relations, or DevRel, helps developers understand and trust a technical product. It also helps them use the product well enough to give useful feedback. In the DataTalks.Club archive, DevRel sits between developer experience, documentation, and technical writing. It also connects open source, product feedback, and community building.

The clearest definition comes from Hugo Bowne-Anderson in DevRel Role for Machine Learning. At 18:03, he describes DevRel around education, documentation, and a “wisdom layer” around tools. At 25:17, he connects the role to dogfooding and developer collaboration. He also names documentation feedback and routing user friction back to the team building the product.

Common Definition in the Archive

Across the DevRel episodes, guests describe the same operating model. DevRel people learn the tool deeply and turn that knowledge into reproducible examples. They help developers get their first useful result, then bring confusing parts back to product and engineering.

Elle O’Brien shows this model in DevRel for Data Science. At 12:20, her role at Iterative spans product work, CML, and documentation. It also includes pull requests, videos, and hiring. At 19:47, she describes the daily reality through content creation, community management, and support. At 23:51, she frames the community-facing role as a product signal channel because DevRel sees where users get confused before roadmap discussions surface those problems.

That makes DevRel more than awareness work because it’s technical adoption work. A DevRel person needs enough software engineering and product fluency to build credible examples. They also need enough writing skill to explain those examples and enough community judgment to notice repeated user friction.

Guest Differences

Guests agree on the bridge role, but they differ on where DevRel should sit and how technical the work should be.

Hugo’s machine learning DevRel episode treats DevRel as close to engineering and product. At 22:52, he discusses reporting lines and technical alignment. At 31:41, he names technical fluency, writing, and community building as core skills. In the same episode, he warns that the role loses credibility when it stops dogfooding the product.

Elle’s episode emphasizes solo prioritization and public exposure. At 15:02, she talks about balancing release support with evergreen content. At 28:55, she discusses online abuse and burnout. At 31:25, she adds anonymity, moderation, and peer solidarity. Her version of DevRel includes emotional and safety costs that don’t show up in a pure developer experience definition.

Vincent Warmerdam pushes the role closer to open-source engineering. In Open Source ML Tools, the 38:22 chapter covers combining DevRel with core development responsibilities. At 41:21, he describes a developer-relations engineer role at :probabl. At 42:20, he connects that role to interactive scikit-learn content and videos.

Will Russell gives a more demo-first version in Developer Advocacy Through Community Impact. At 49:14, he describes developer advocacy at Kestra through documentation, demos, and outreach. At 51:49, he explains a content flow based on bullet points, demos, and collaboration with writers.

Education and Documentation

DevRel people turn internal product knowledge into public learning paths. Hugo’s 18:03 definition places education and documentation at the center of the job. In the 43:14 chapter, he argues that tutorials should start from audience and goals, not from the feature a team wants to announce.

Elle’s episode adds the data-science version of the same structure. At 7:50, she discusses applied data science teaching and reproducibility. At 52:06, she links teaching with DevRel through curriculum design and reusable video content. That connects DevRel directly to technical writing and documentation. The work goes beyond publishing docs because developers still need to succeed with the tool in a real context.

Eugene Yan gives the writing side of this work in Technical Writing for Data Scientists. At 14:00, he talks about choosing readers, peers, and future teammates. At 54:00, he treats technical documentation as decision logs, rationales, and team memory. DevRel uses the same writing muscles, but it points them toward external developer adoption.

Demos and Developer Experience

Demos matter because they show the first useful path through a tool. A demo is weak when it only sells the feature. It’s useful when it reduces setup uncertainty, shows the tool in context, and exposes the tradeoffs a real user will hit.

Will’s Kestra episode gives the strongest demo reference. At 53:40, he explains a video strategy built around a clear goal and a useful pace. He also argues for full walkthroughs. At 54:30, he uses an “after execution” notification as a concrete feature demo.

At 57:22, his “Learn with Kestra” series uses adjacent tools like Docker and Postgres. He includes Git too because developer adoption often depends on the surrounding work, not only the main product.

Hugo’s Metaflow episode gives the ML infrastructure version. The 2:14 chapter uses a Metaflow sandbox demo, and the 36:27 chapter connects teaching reproducibility with dogfooding and simplified workflows. Those examples belong with Metaflow, MLOps, and machine learning tools because the demo is also a test of the tool’s developer experience.

Community and Open Source

DevRel often runs through public communities, but it isn’t the same job as general community management. In MLOps Community Playbook, Demetrios Brinkmann focuses on launching, growing, and retaining a community. At 24:57, he describes the shift from founder-led activity to peer-to-peer participation. At 55:04, he discusses sprints, autonomy, and many-to-many engagement.

DevRel can use those habits, but its product responsibility is narrower. DevRel helps developers adopt the tool and routes technical feedback back to the builders.

Open-source DevRel has an extra constraint because the project community must keep its own credibility. In ETL vs ELT & Data Lake vs Warehouse, Natalie Kwong explains Airbyte’s open-source plus cloud model at 43:45. At 48:26, she discusses competition and licensing risk.

Vincent’s scikit-learn episode adds governance pressure. At 10:28, he covers scikit-learn governance and project history, and at 18:11 he discusses maintainer transition. DevRel work in that setting has to respect governance and maintainers while supporting contribution paths and long-term trust.

This is why the archive links DevRel closely to open source and developer relations, contributing, and open-source portfolio evidence. Docs fixes and examples can be real technical contributions when they remove adoption friction. The same is true for reproducible issues, workshops, and demo repos.

Metrics and Feedback

DevRel metrics are useful when they track developer progress, not only audience size. Elle’s 26:01 chapter covers community signals and analytics. At 48:06, she contrasts audience growth with sustainable strategies. Hugo’s 46:09 chapter separates content goals such as awareness, support, and open-source strategy.

Useful metrics include successful first runs, activated users, and repeated usage. Docs issues and unanswered support questions also matter when they change the tool. The same is true for contribution flow, event follow-up, and product feedback. Vanity metrics can still help with distribution, but they don’t prove adoption by themselves.

A tutorial view, a conference talk, or a social post matters more when it leads to a working project or a clearer issue. A better doc page or a product fix matters too.

Community metrics have a different center of gravity. Demetrios discusses membership milestones at 18:21, surveys and feedback cadence at 45:45, and member connections at 50:51. Those metrics measure community health. DevRel can borrow them, but it still needs product-facing signals that tell engineering where developers get stuck.

Boundaries with Marketing and Community

DevRel overlaps with marketing because both care about reach, messaging, and distribution. Hugo makes that overlap explicit at 27:17 when he discusses SEO, content strategy, and audience targeting. The credibility boundary matters because practitioners should be able to reproduce the demo, look at the code, or connect what they learned to real work.

Ben Taylor shows the evangelism side in Public Speaking for Data Scientists. At 6:04, he discusses AI evangelism, positioning, and messaging strategy. At 21:55, he recommends one to three clear takeaways and calls to action. That skill helps DevRel, but it doesn’t replace the technical feedback loop.

A good talk can drive awareness, while a good DevRel program also improves docs, examples, and onboarding. It should also improve support and product decisions.

DevRel also overlaps with community, so the ownership boundary matters here too. Community work creates belonging, moderation, and member-to-member connection. Events and shared identity belong on the community side. DevRel uses those channels to teach, listen, test examples, and support adoption.

When a company turns every community interaction into a campaign, it weakens trust. When DevRel disconnects from product and engineering, it becomes only broadcasting.

Follow these pages for adjacent topics in the archive.