## Summary A week-by-week discovery guide for someone starting a new Developer Relations role. The first month is structured to map the company before producing anything: learn the developer-facing products, build a shared definition of DevRel, interview stakeholders, then audit the developer experience firsthand. The goal is a grounded foundation and stakeholder buy-in before committing to a program. ## Key Points - Week 1 — understand the company landscape: research developer products, monetization, personas, value proposition, product-market fit, and competitors. - Week 2 — prepare a "What is DevRel" presentation and schedule stakeholder calls to set a shared definition and find early allies. - Week 3 — run stakeholder interviews across sales, marketing, customer success, product, and engineering; listen for goals, priorities, and buy-in gaps. - Week 4 — perform a developer experience audit: walk the products, docs, and communications as a developer would, down to time-to-"Hello World." - Iterate on the answers as you grow into the role; the early questions aren't one-and-done. ## Claim Atoms - **DevRel onboarding should map before it makes** — the first 30 days are discovery and listening, not output. - **Time-to-"Hello World" measures developer experience** — the week 4 audit checks how long onboarding actually takes. - **A shared "What is DevRel" definition wins buy-in** — week 2's presentation aligns cross-functional partners early. ## Links - [[DevRel MOC]] — places the onboarding framework within the broader map of DevRel practice and program design. - [[Time-to-Hello-World Is the Critical Developer Experience Metric]] — applies-in: the week-four product walkthrough turns a broad DX audit into a measurable first-success interval. - [[Empowerment Without Clarity Is Abdication]] — extends: the shared DevRel definition and stakeholder interviews establish the outcome clarity required before a new practitioner acts autonomously.