Reactive versus proactive strategies for developer relations
summary
Argues proactive DevRel beats reactive: set quarterly objectives, measure impact with retrospectives, and avoid being pulled into every request or dying within 6–12 months. Recommends the three Cs—code content community—plus executive buy‑in, a budget, and a rule to give back ten times before asking once. Cites concrete programs that worked: GitHub Student Pack, Glitch collaborations, Algolia donations and the SendGrid Taco Bell email hack that caused a traffic spike teams had to handle.
AI-written summary · about
chapters (7)
- 0:00Introduction to devrel
- 1:37Reactive strategies
- 3:40Common pitfalls in devrel
- 7:29Building proactive strategies
- 12:26Leadership and alignment
- 14:43Metrics and military tactics
- 17:42Executing for long-term success
related talks
40mHow to market to developers during a recession
29mSupporting Low Resource Regions with your Dev Rel Strategy
33mThe Strategic Power of DevRel: From Community to Business Impact
01h 10mLife as a DevRel Panel
40mForging Your Career in DevRel Advocate to Exec
25mThe importance of personal brand in DevRel
30mDevRel is a lie
32mThe Four Pillars of Support in Developer Relations