What problem does it solve? Deciding where developer relations should report, how to shape the team, and who owns which surfaces is a recurring political fight with no industry consensus. This Skill turns that argument into a structured decision process that ends in a written, approvable DevRel org design brief. ## Core Features & Use Cases - Reporting line decision: Chooses between marketing, product, engineering, CEO, or sales based on the funded driver, and forces each choice to name what it starves and who covers the gap. - Team shape selection: Evaluates centralized, hub-and-spoke, split-by-focus, and embedded shapes against staffing floors, coordination cost, and reversibility, deleting shapes the headcount rules out. - Coverage and interlocks: Maps the six DevRel functions to owned/shared/unowned/refused states and writes one Team Topologies interaction mode per adjacent team with a named arbiter. - Use Case: A COO must settle whether three DevRel people report to the VP Marketing or the new VP Engineering before a leadership offsite. The Skill refuses to pick a line until the funded driver is named, then produces a four-part line statement with a review date. ## Quick Start Ask the assistant to design your developer relations org structure, for example: "Our devrel team reports to the CTO and it isn't working - help me decide where it should sit and how to structure it."