samber/developer-relations-skillsチェック済み
SKILL DETAIL
devrel-team-structure
samber/developer-relations-skills/devrel-team-structure
Designs the developer relations org - which function DevRel reports to (marketing, product, engineering, CEO, sales) and what that line starves, the shape (centralized, split, embedded, hub-and-spoke), the coverage map across advocacy, community, docs and education, the interlocks with product, docs, support and sales, and the trigger for the next re-org. Use whenever someone asks where DevRel should sit, who DevRel should report to, how to structure or restructure a devrel team, which devrel roles to staff at this size, whether to embed advocates in product teams, why devrel keeps getting pulled into other teams' work, or how devrel and docs divide ownership - even if they only say the team feels wrong. Not the budget split - use samber/developer-relations-skills@devrel-budget-allocation.
インストール · 410出典を見る
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill devrel-team-structure
スキルファイル
SKILL.md
最終同期 · 2026/10/23
evals/evals.json›
{
"skill_name": "devrel-team-structure",
"evals": [
{
"id": 1,
"prompt": "I'm COO at Mosswell, payments infrastructure, 60 people, Series A. Three people do developer relations and all three sit under our VP Marketing today. Our new VP Engineering started six weeks ago and says they should report to him because \"devrel is an engineering function\". The VP Marketing says she's had the budget for two years and it's working. I have to settle this before Friday's leadership offsite. Which one is right?",
"expected_output": "A refusal to name a line until the funded driver is identified and attributed to a named leader, an interview that asks for that driver and the political constraints, the survey spread showing no line holds a majority, and a four-part line statement naming the starved pillar and its cover with a review date - preceded by a demand for the work inventory.",
"files": [],
"expectations": [
"Does not name a reporting line before the funded driver is identified and attributed to a named leader.",
"Asks explicitly why the company funds developer relations, offering driver options such as developer adoption, sales enablement, developer enablement, product input, ecosystem, contributor community or employer brand.",
"States that no reporting line holds a majority across the field, so placement is a trade-off rather than a best practice.",
"Quotes the reporting-line spread with the survey year attached (marketing around 33%, product around 22%, CEO around 20%, engineering around 20%, sales around 3%).",
"Any reporting-line recommendation is written with all four parts: the function, the funded driver plus the named leader who owns it, the pillar that line starves, and the named person or team covering that gap.",
"Sets a review date or an explicit review trigger on the reporting-line decision.",
"Names what an engineering line starves (narrative, measurement literacy or budget defence) and its characteristic failure of the team being used as overflow engineering capacity.",
"Names what a marketing line starves (the product feedback loop, or technical credibility over time).",
"Asks what is politically fixed - a line that cannot move, or a manager who cannot be moved.",
"Requires a work inventory listing each recurring surface with a named owner, that owner's manager, hours per week, and what breaks if the surface stops, before proposing any structure.",
"Quotes no advocate-to-developer or advocate-to-product-line headcount ratio."
]
},
{
"id": 2,
"prompt": "Sedgeline API here. We have 84,000 registered developers and 12,000 monthly active ones, and exactly two developer advocates. My CFO wants the industry benchmark ratio of advocates to registered developers so I can justify a request for four more heads in the January planning round. What's the number, and what does it make our target headcount?",
"expected_output": "A refusal to supply a ratio, with the reason, followed by a surface-inventory derivation: every committed surface with a named owner, a backup, real hours per week, and what breaks if it stops, planned against 70% of declared capacity labelled as a chosen baseline.",
"files": [],
"expectations": [
"Refuses to supply an advocate-to-developer ratio as a benchmark.",
"States that every circulating headcount ratio is a single-company anecdote rather than a measured standard.",
"Derives the headcount from an inventory of recurring surfaces instead of from a ratio.",
"Asks for or lists the recurring surfaces the company has committed to (docs, quickstart, blog, community venue, event calendar, SDKs, sample apps, changelog, support presence, repositories).",
"Records a named person as owner today for each surface, plus that person's manager.",
"Records hours per week each surface really takes.",
"Records what happens if each surface stops.",
"Marks each surface as owned, shared, unowned, or informally absorbed by someone with a different job title.",
"Plans against at most 70% of declared capacity.",
"Labels the 70% ceiling as a chosen, adjustable baseline rather than an industry standard or benchmark.",
"Requires one accountable owner plus one named backup per surface, and flags any surface at a bus factor of one as a risk.",
"States in the answer that the headcount figure was derived from the surface table, and quotes no compensation band."
]
},
{
"id": 3,
"prompt": "Riverbend Analytics, developer tooling. I run devrel: seven people, but only five are full-time on it - the other two split their week with support. We have four product lines. I want to move us to hub-and-spoke like the big API companies run: a central hub of two owning standards and tooling, plus one spoke per product line. Board review is in five weeks and I'd like to present this. Draft the new structure for me.",
"expected_output": "A rejection of hub-and-spoke at this headcount against its stated staffing floor, centralized recommended as the only affordable shape under roughly ten full-time people, the ruled-out shapes deleted by name, and the near board date noted as promoting centralized.",
"files": [],
"expectations": [
"Rejects hub-and-spoke at this headcount rather than shrinking it to fit.",
"States the hub-and-spoke staffing floor: a hub of two to three plus at least two spokes, a management layer and a standing forum.",
"Notes hub-and-spoke takes about a quarter to stand up and a quarter to unwind.",
"Points out four spokes cannot be staffed from five full-time people.",
"Recommends centralized as the only candidate shape under roughly ten full-time people.",
"Labels the ten-person threshold as this skill's own chosen baseline, not a published finding.",
"Cites that around 69% of surveyed teams are under ten people, with the year attached.",
"Deletes the ruled-out shapes explicitly and names which ones were deleted, rather than parking them at the bottom of a list as later options.",
"Warns that copying a larger company's shape presupposes spokes this company cannot staff.",
"Applies the scaling test: further investment must increase output more than it increases input.",
"Warns that a hub that approves work rather than enables it becomes a bottleneck wearing a standards label.",
"States that the near board date pushes the choice toward centralized, which is reversible in about a week and adds near-zero coordination."
]
},
{
"id": 4,
"prompt": "Halcyon Robotics. Six advocates in one central team today, all reporting to me. Five product squads. Our CTO wants each squad to get its own advocate reporting to that squad's engineering manager, starting next quarter - his argument is that advocates will finally be close to the code. The reason the company funds devrel is that sales keeps losing enterprise deals to a competitor whose integration docs are better. Write me the plan for the move.",
"expected_output": "The embedded shape tested against all four promotion conditions, failing on the funded driver, with the ladder and reversibility consequences named, the staffing floor computed, and sales enablement routed to a product or marketing line with a sales interlock instead.",
"files": [],
"expectations": [
"Tests the embedded shape against all four promotion conditions before recommending or rejecting it.",
"States that the funded driver here is not product input, so embedded fails at least one of the four conditions.",
"Requires each host team to be able to fund and level the advocate role, not just host it.",
"Requires a named craft owner who survives outside the host teams.",
"Requires the product lines to have genuinely different audiences.",
"States that embedded is the least reversible shape, because each advocate is levelled and promoted by a host manager who now owns that headcount.",
"Names the career ladder as what embedded usually costs.",
"Names the shared craft and the shared calendar as what embedded costs.",
"Acknowledges that embedded buys the best product feedback available, and does not reject it as simply wrong.",
"States that embedded's coordination is a standing job rather than a one-off setup cost.",
"Gives the embedded staffing floor as one advocate per host team plus a craft owner somewhere, i.e. at least five advocates plus a craft owner for five squads.",
"Routes the sales-enablement driver to a product or marketing line with a sales interlock, and does not place developer relations under sales."
]
},
{
"id": 5,
"prompt": "Tervo Systems, about 120 engineers. For three months now two of my devrel people and the docs team lead have been arguing over who owns the API reference and who owns the tutorials. Docs reports into engineering; devrel reports to me, I'm the CMO. Both sides escalate to me roughly weekly. I'm close to just folding the docs team into devrel so there's one owner. Tell me how to structure that merge.",
"expected_output": "Two interlock lines plus a named arbiter instead of a merge, one mode per adjacent team, the docs coverage state recorded on the six-function map, and the warning that reorganising here substitutes for declaring ownership.",
"files": [],
"expectations": [
"Produces interlock lines and a named arbiter rather than recommending the merge as the first move.",
"Assigns exactly one interaction mode to the docs / technical-writing team.",
"Names the mode as one of collaboration, X-as-a-service or facilitation, and attributes the model to Team Topologies.",
"Names X-as-a-service as the default mode for docs drafts, reviews and structure decisions.",
"Writes each interlock with what crosses the boundary.",
"Writes each interlock with who arbitrates when it stalls.",
"States that more than one mode per adjacent team means nobody can say where the boundary is.",
"Cites that technical writing is staffed on around 42.7% of surveyed teams, with the year attached, and sits under another manager in most of the rest.",
"Names leaving docs ownership implicit as the failure that produces gaps exactly between the two orgs.",
"States that collaboration mode needs an end date or the team silently becomes interrupt-driven.",
"Warns against reorganising when the real fix is declaring ownership and re-scoping.",
"Records technical writing on the six-function coverage map as owned by another named team or shared with a named split, in writing."
]
},
{
"id": 6,
"prompt": "Ashgrove Cloud - we sell an observability agent to platform teams. I lead devrel, four people, currently under product marketing. Our CRO wants us to report into sales starting next quarter so we can finally attribute pipeline properly, and he's offering to fund two extra heads immediately out of the sales budget if we move. Honestly the money is tempting and nobody else is offering headcount. Talk me through how to make the move work.",
"expected_output": "A recommendation against the sales line with its genuine upside named, the starved pillars and characteristic failure stated, the rarity figure cited with its year, and a product-or-marketing placement with a capped X-as-a-service sales interlock and a matching re-org trigger.",
"files": [],
"expectations": [
"Recommends against the sales reporting line.",
"Names attribution speed and pipeline visibility as what the sales line genuinely optimizes.",
"Names trust, community, and any work with a horizon longer than the quarter as what the sales line starves.",
"Names the characteristic failure: advocates become pre-sales engineers and the community reads the program as a sales channel.",
"Cites the sales share of reporting lines at around 3.2%, with the year attached.",
"Proposes placing the team in product or marketing and giving sales a service interlock instead of the reporting line.",
"Sets the sales interlock mode to X-as-a-service.",
"States what crosses that boundary: evaluation material out, field objections in.",
"Names an arbiter for the sales interlock.",
"Proposes an observable cap on the sales interlock's load, such as hours per week.",
"Adds a re-org trigger tied to that interlock breaching its cap or staying in collaboration mode past its end.",
"Does not treat the two funded heads as settling the reporting-line question on their own."
]
},
{
"id": 7,
"prompt": "Founder and CEO of Dunmere here, developer tooling, 25 staff. Devrel is two people and they report straight to me because I started the program myself and I still do a lot of the community work. It genuinely works well. I'm now hiring a Head of Developer Relations to run it. Three questions: what level should that title be, what should I pay for it in a European market, and should the role keep reporting to me?",
"expected_output": "A refused compensation band with the reason and a pointer to live market data, a re-decision date attached to the CEO line with the destination function named, the starved pillars stated, the \"Head of\" title resolved to a real level, and the ladder named.",
"files": [],
"expectations": [
"Refuses to state a compensation band or salary figure.",
"States that developer relations roles are thin in salary-banding datasets, so a quoted band is guesswork, and points the user to live market data.",
"Keeps compensation out of the org design brief entirely rather than including it with a caveat.",
"Attaches a re-decision date to the CEO reporting line.",
"Names the function the team moves to when it crosses a stated size threshold.",
"Names what the CEO line starves: operational support, career ladder, peer review, or everyday prioritization.",
"Names the characteristic failure: the line survives exactly as long as the founder's attention, leaving no manager who knows how to grow the discipline.",
"Flags \"Head of\" as ambiguous both internally and on the market and resolves it to a real level.",
"Checks the title against scope: a manager accountable for company-level goals warrants a director-level title and influence.",
"States which career ladder the role sits on - engineering, marketing, or a developer-relations-specific one.",
"Warns that a borrowed ladder promotes against criteria that do not describe the work, which leaks retention slowly rather than failing loudly.",
"Cites that the CEO line has grown to around 20% of surveyed teams, up from around 14%, with the year attached."
]
},
{
"id": 8,
"prompt": "Larkfield Identity, Series B. Eleven people do developer-relations work but they're spread across three groups: four under product marketing, five under platform engineering, and two contractors handling the docs site. The company funds this to drive self-serve signups. I'm the new VP who inherited all of it, and I need a structure proposal to take to the exec team in two weeks. Give me your recommendation.",
"expected_output": "An explicit brainstorming pass producing two or three whole candidate structures (line plus shape plus coverage each), ordered by efficiency with a stated recommendation and the choice left open, then the brief delivered one section at a time.",
"files": [],
"expectations": [
"States explicitly that it is in brainstorming mode before recommending anything.",
"Builds two or three whole candidate structures, each combining a reporting line, a shape and a coverage split as one set.",
"States the headcount each candidate assumes.",
"States the weekly coordination each candidate adds and what undoing it would take.",
"States what each candidate makes easy and what it makes hard.",
"States the first thing that would break under each candidate.",
"States the conditions under which each candidate is the wrong pick.",
"Orders the candidates by efficiency - value per unit of effort - and says the ordering out loud rather than implying it by row order.",
"Recommends one candidate and gives the reason.",
"Leaves the choice to the accountable person before detailing anything below the recommendation.",
"Presents the brief one section at a time and seeks agreement before writing the next section.",
"Cites that around 43.6% of surveyed teams already have more than one team doing developer-relations work, with the year attached, and treats redrawing boundaries around existing owners as the starting condition.",
"States that the contracted docs work still needs one internal accountable owner, or it disappears the day the contract ends."
]
},
{
"id": 9,
"prompt": "Vantor Mesh. Devrel is five people, sitting under product for the last 18 months, and we have missed every goal two quarters running. Our new VP Product started last month and wants to restructure: move us to marketing and split us into a content pod and a community pod under separate leads. Here is what we currently run: API docs, an engineering blog, a product blog, a Discord, a monthly webinar, three SDKs, the sample apps repo, a champions program, a conference track, a YouTube channel, the changelog, and our Stack Overflow presence. What should the new structure be?",
"expected_output": "A surface-count diagnosis ahead of any structural move, the split shape rejected against its roughly eight-person floor with the shared-voice cost named, specific surfaces moved, refused in writing or staffed, and an observable re-org trigger list replacing a calendar review.",
"files": [],
"expectations": [
"Checks the surface count against team capacity before proposing any new parent or shape.",
"States that a program missing its goals has usually funded too many surfaces rather than chosen the wrong parent.",
"Rejects the split-by-focus shape at five people.",
"States the split-by-focus staffing floor of roughly eight, because each half needs a viable team.",
"Names the shared-voice problem a split creates: two teams, one audience, two calendars, two metric sets.",
"Notes that unwinding a split needs two leaders to agree to give up a team, and that its coordination cost is permanent rather than setup.",
"Names the one-re-org-per-new-leader pattern and prices each redraw at roughly a quarter of rebuilding interlocks.",
"Proposes moving, refusing or staffing specific named surfaces from the list as the remedy.",
"States that a refused surface must be refused in writing.",
"Requires planned work to fit inside 70% of stated capacity and says that ceiling is a chosen baseline.",
"Produces a re-org trigger list written as observable conditions rather than calendar dates, and does not propose an annual review as the mechanism.",
"The trigger list includes a change in the funded driver or the departure of the sponsor who owns it.",
"The trigger list includes a surface sitting at a bus factor of one for a quarter."
]
},
{
"id": 10,
"prompt": "Corvid Freight, logistics API. Developers do the integration but a VP of Operations signs the contract and runs a security review first. Devrel is nine people under marketing. I want to add a management layer: one lead for content with two reports, one lead for events and field with six reports, and both to me. Separately, tell me which developer-relations functions we should actually be staffing at our size and audience.",
"expected_output": "Both spans questioned with the check attributed to general management practice, all six functions marked with one of the five coverage states against the survey shares, and the mix weighted toward enablement, DX engineering and technical writing because the approver reads documents.",
"files": [],
"expectations": [
"Questions both proposed spans - the two-report lead and the six-report manager - rather than approving the layer as drawn.",
"States that the span-of-control check comes from general management practice, not from developer-relations data.",
"States that no developer-relations-specific span-of-control data exists.",
"Marks all six functions - advocacy, community management, technical writing, developer marketing, developer education, developer-experience engineering - with one of the five coverage states.",
"Leaves no function blank on the coverage map.",
"Treats an unowned function as a recorded decision rather than hiding it as an embarrassment.",
"Cites the survey coverage shares with the year attached (advocacy around 82%, community around 53%, technical writing around 43%, developer marketing around 38%, developer education around 36%, developer-experience engineering around 27%).",
"Weights the mix toward enablement, developer-experience engineering and technical writing because the approver is an enterprise buyer.",
"States that the artefacts an approver reads are documents rather than talks.",
"Ranks the individual-developer and enterprise audiences for this horizon instead of splitting effort evenly between them.",
"States that consumer-marketing org patterns do not transfer, because a developer audience evaluates the artefact rather than the campaign.",
"Applies the awareness / enablement / engagement split across advocates, developer experience and community management, attributed to Mary Thengvall."
]
}
],
"trigger_queries": [
{ "query": "Who should DevRel report to?", "should_trigger": true },
{ "query": "Should developer relations sit under marketing or under product?", "should_trigger": true },
{ "query": "Our devrel team reports to the CTO and it isn't working - where should they go instead?", "should_trigger": true },
{ "query": "We're going from 4 to 11 devrel people next year, how should I structure the team?", "should_trigger": true },
{ "query": "Should each product squad get its own developer advocate?", "should_trigger": true },
{ "query": "How do I split ownership between devrel and the docs team?", "should_trigger": true },
{ "query": "What's the right ratio of advocates to developers?", "should_trigger": true },
{ "query": "Design our developer relations org", "should_trigger": true },
{ "query": "I need an org design brief for our devrel function", "should_trigger": true },
{ "query": "Our advocates keep getting pulled into pre-sales calls - is that a structure problem?", "should_trigger": true },
{ "query": "Should we embed advocates inside the engineering teams?", "should_trigger": true },
{ "query": "Two different teams here are both doing devrel work and they keep colliding", "should_trigger": true },
{ "query": "My developer relations team feels wrong and I can't articulate why", "should_trigger": true },
{ "query": "hub and spoke or centralized for devrel?", "should_trigger": true },
{ "query": "Which devrel roles should we staff now that we're eight people?", "should_trigger": true },
{ "query": "Our CRO wants to take over the developer advocacy team", "should_trigger": true },
{ "query": "Who owns the quickstart - docs or devrel?", "should_trigger": true },
{ "query": "We need to restructure developer relations before the board meeting", "should_trigger": true },
{ "query": "What does a devrel team of 15 actually look like?", "should_trigger": true },
{ "query": "Is it normal for developer relations to report to the CEO?", "should_trigger": true },
{ "query": "Our community manager, technical writer and two advocates all report to different people. Is that a problem?", "should_trigger": true },
{ "query": "Should I split my devrel team into an awareness team and an enablement team?", "should_trigger": true },
{ "query": "how do i stop devrel work falling through the cracks between teams", "should_trigger": true },
{ "query": "Write the interlocks between developer relations and product", "should_trigger": true },
{ "query": "When should devrel stop reporting to the founder?", "should_trigger": true },
{ "query": "We reorganise devrel every time a new VP joins. How do I make it stop?", "should_trigger": true },
{ "query": "My advocates are being used as overflow engineers", "should_trigger": true },
{ "query": "Do we need a developer experience engineer or another advocate next?", "should_trigger": true },
{ "query": "Which career ladder should our developer advocates sit on - engineering or marketing?", "should_trigger": true },
{ "query": "how should developer relations and developer marketing divide the work?", "should_trigger": true },
{ "query": "Structure a devrel team for a company with 3 product lines and 6 SDK languages", "should_trigger": true },
{ "query": "Nobody owns our Discord since the community manager left - how do I fix the org?", "should_trigger": true },
{ "query": "Our devrel team is two people and we're being asked to cover eleven different surfaces", "should_trigger": true },
{ "query": "Give me a reporting-line recommendation for developer advocacy", "should_trigger": true },
{ "query": "Should the technical writers sit inside devrel?", "should_trigger": true },
{ "query": "We're merging two devrel teams after an acquisition - how do we draw the new boundaries?", "should_trigger": true },
{ "query": "org chart for developer relations at a Series B", "should_trigger": true },
{ "query": "What should trigger the next redesign of our devrel team?", "should_trigger": true },
{ "query": "Is \"Head of DevRel\" the right title for someone managing three people?", "should_trigger": true },
{ "query": "How many people do I actually need on devrel?", "should_trigger": true },
{ "query": "My devrel team says yes to everything and is burning out - is this an org problem?", "should_trigger": true },
{ "query": "Where should developer education sit in the org?", "should_trigger": true },
{ "query": "Our developer advocates report to the VP of Marketing and the product team never hears from them", "should_trigger": true },
{ "query": "planning a devrel reorg for next quarter", "should_trigger": true },
{ "query": "Who arbitrates when devrel and support disagree about who answers forum questions?", "should_trigger": true },
{ "query": "Should devrel be one team or several?", "should_trigger": true },
{ "query": "We just hired a VP of Developer Relations. What should sit under them?", "should_trigger": true },
{ "query": "I have budget for two more devrel heads - which roles, and who do they report to?", "should_trigger": true },
{ "query": "One advocate in each region, or one central team?", "should_trigger": true },
{ "query": "devrel org design", "should_trigger": true },
{ "query": "Our developer relations function is split across marketing and engineering and I want to consolidate it", "should_trigger": true },
{ "query": "How do I write down the boundary between devrel and customer success?", "should_trigger": true },
{ "query": "Does developer relations belong under product?", "should_trigger": true },
{ "query": "Nobody here knows who owns what in our developer program", "should_trigger": true },
{ "query": "Write a job posting for a senior developer advocate", "should_trigger": false },
{ "query": "Design the interview loop for a community manager hire", "should_trigger": false },
{ "query": "Build a 30-60-90 ramp plan for our new developer advocate", "should_trigger": false },
{ "query": "Score this developer advocate portfolio against a hiring rubric", "should_trigger": false },
{ "query": "I want to become a developer advocate - what should my portfolio look like?", "should_trigger": false },
{ "query": "How do I get promoted from senior advocate to staff advocate?", "should_trigger": false },
{ "query": "Split our devrel budget across events, content and community", "should_trigger": false },
{ "query": "How much of our devrel budget should go to conferences?", "should_trigger": false },
{ "query": "Which devrel metrics should I report to the board?", "should_trigger": false },
{ "query": "How do I prove devrel ROI to my CFO?", "should_trigger": false },
{ "query": "Should we start doing devrel at all?", "should_trigger": false },
{ "query": "What should our devrel program focus on in its first year?", "should_trigger": false },
{ "query": "Who are our developers actually, as segments?", "should_trigger": false },
{ "query": "Which developer audience should we serve first?", "should_trigger": false },
{ "query": "Should we start a Discord for our users?", "should_trigger": false },
{ "query": "Our Discord is dying - which community health metrics should I track?", "should_trigger": false },
{ "query": "Write a code of conduct for our developer community", "should_trigger": false },
{ "query": "Design a moderator escalation ladder for our forum", "should_trigger": false },
{ "query": "Set up a developer champions program with perks and terms", "should_trigger": false },
{ "query": "Plan a recurring monthly developer meetup in Berlin", "should_trigger": false },
{ "query": "Which conferences should we sponsor this year and at which tier?", "should_trigger": false },
{ "query": "Plan a quarter of devrel content with owners and dates", "should_trigger": false },
{ "query": "Build a tracking plan for our docs analytics", "should_trigger": false },
{ "query": "Benchmark a competitor's devrel motion from public signals", "should_trigger": false },
{ "query": "Give me a watch list of devrel podcasts and newsletters", "should_trigger": false },
{ "query": "Route my current devrel task to whichever skill fits", "should_trigger": false },
{ "query": "Audit our docs structure against Diataxis", "should_trigger": false },
{ "query": "Write a quickstart for our REST API", "should_trigger": false },
{ "query": "Map the developer journey for our enterprise segment", "should_trigger": false },
{ "query": "Who decides what gets merged in our open-source project?", "should_trigger": false },
{ "query": "How do I promote a contributor to maintainer?", "should_trigger": false },
{ "query": "Design an issue and PR triage system for our repo", "should_trigger": false },
{ "query": "Should we open source our scheduler?", "should_trigger": false },
{ "query": "Design our developer education curriculum and certification", "should_trigger": false },
{ "query": "How should we price our developer tool?", "should_trigger": false },
{ "query": "Open core or hosted open source for our business model?", "should_trigger": false },
{ "query": "Design the go-to-market motion for a developer-first product", "should_trigger": false },
{ "query": "Build an employer brand plan to attract backend engineers", "should_trigger": false },
{ "query": "Should our product become a platform other companies build on?", "should_trigger": false },
{ "query": "How should I structure my engineering organization?", "should_trigger": false },
{ "query": "Apply Team Topologies to our platform engineering group", "should_trigger": false },
{ "query": "Define a stream-aligned team boundary for our payments squad", "should_trigger": false },
{ "query": "How many direct reports should an engineering manager have?", "should_trigger": false },
{ "query": "Restructure our customer success team", "should_trigger": false },
{ "query": "Sales team structure for a 20-person SaaS company", "should_trigger": false },
{ "query": "How should a marketing team be organized at Series A?", "should_trigger": false },
{ "query": "Should our platform engineering team be centralized or federated?", "should_trigger": false },
{ "query": "Write the charter for our internal developer platform team", "should_trigger": false },
{ "query": "Draw an org chart for our data team", "should_trigger": false },
{ "query": "Should QA be embedded in product squads or run as a separate team?", "should_trigger": false },
{ "query": "Build a RACI matrix for our product launch process", "should_trigger": false },
{ "query": "Write the internal announcement email for our engineering re-org", "should_trigger": false },
{ "query": "What's the right span of control for a support organization?", "should_trigger": false },
{ "query": "How do I structure a scrum team?", "should_trigger": false }
]
}
references/org-design-brief-example.md›
# Worked org design brief
An illustrative brief for a fictional Series-B payments-API company with four people doing DevRel work. Use it for shape and level of detail, not as a template to fill with the same answers.
---
# DevRel org design brief - Northbank API, March
## Table of Contents
- [Situation](#situation)
- [Work inventory](#work-inventory)
- [Reporting line](#reporting-line)
- [Shape](#shape)
- [Coverage](#coverage)
- [Roles](#roles)
- [Interlocks](#interlocks)
- [Ladder and titles](#ladder-and-titles)
- [Budget](#budget)
- [Re-org triggers](#re-org-triggers)
- [Transition](#transition)
- [Weak versus strong, on the contested sections](#weak-versus-strong-on-the-contested-sections)
## Situation
The community manager resigned; her replacement req is being held while leadership argues whether DevRel should move from marketing to product. Funded driver: developer adoption - developers pick the API, and a finance lead signs. Sponsor: VP Marketing, who has held the budget for two years.
## Work inventory
| Surface | Owner today | Manager | Hours/week | If it stops |
| ----------------------------- | ------------------------ | --------------- | ---------- | ----------------------------------------------- |
| API docs | 1 technical writer | Eng manager | 30 | Support volume rises within two weeks |
| Quickstarts and samples | Advocate A | VP Marketing | 8 | Trial activation drops, invisible for a quarter |
| Blog | Advocate A + 3 engineers | VP Marketing | 10 | Organic traffic decays over months |
| Discord (2,400 members) | vacant since February | - | 12 | Already degrading: median first response 4 days |
| Conference talks | Advocate B | VP Marketing | 12 | Nothing immediate |
| SDK maintenance (5 languages) | 2 platform engineers | Eng manager | 6 | Issues age, integrations break on API changes |
| Changelog | Product manager | Head of Product | 2 | Customers miss breaking changes |
Unowned since February: community. Informally absorbed: Advocate A is answering Discord between other work, which is why sample apps slipped two quarters.
## Reporting line
DevRel reports to marketing, because the funded driver is developer adoption and the VP Marketing owns it. This line starves the product feedback loop. The head of product covers it through a standing 30-minute roadmap slot every two weeks, owned by Advocate B. Reviewed in September, or immediately if the sponsor changes.
## Shape
Centralized, four people plus the docs interlock. Rejected embedding advocates in the two product squads: with four people, each squad would get half a person and the craft would have no owner. Revisit at eight people.
## Coverage
| Function | State |
| -------------------------------- | ------------------------------------------------------------- |
| Developer advocacy | owned |
| Community management | unowned - this brief's primary gap |
| Technical writing | owned by engineering (1 writer), shared review with DevRel |
| Developer marketing | shared: DevRel writes, marketing distributes |
| Developer education | deliberately refused this year - no certification, no academy |
| Developer experience engineering | owned by platform engineering, service interlock |
## Roles
| Person | Surfaces owned | Backup | Capacity assumption |
| ------------------------------ | -------------------------- | ------------------------ | ----------------------------------------- |
| Advocate A | quickstarts, samples, blog | Advocate B | 70% of 4 days (1 day on support rotation) |
| Advocate B | talks, roadmap interlock | Advocate A | 70% |
| Community manager (open req) | Discord, champions pilot | Advocate A until month 3 | 70% |
| Technical writer (dotted line) | API docs | none - flagged risk | not DevRel-controlled |
Bus-factor-one risks: API docs, and the changelog while it stays with one PM.
## Interlocks
- Product - collaboration during launch windows, X-as-a-service otherwise - feedback in, launch dates out - arbiter: head of product.
- Engineering - facilitation - technical review in, writing coaching out - arbiter: eng manager.
- Docs - X-as-a-service both ways - drafts and structure decisions - arbiter: eng manager.
- Support - X-as-a-service - recurring failure signals in, troubleshooting pages out - arbiter: support lead.
- Sales - X-as-a-service, capped at four hours per week - evaluation material out, objections in - arbiter: VP Marketing.
## Ladder and titles
Advocates sit on the marketing ladder, which levels on campaign ownership and does not describe their work. Action: adopt the engineering IC ladder's levels with DevRel-specific criteria, drafted by June. The "Head of DevRel" title on the open req maps to a manager-of-three scope - leave it at manager until the team clears six people.
## Budget
- Headcount budget: VP Marketing.
- Program budget (events, community tooling, swag): VP Marketing.
- Docs headcount: eng manager.
Confirmed unusual - most programs have these split across two owners.
## Re-org triggers
- Sponsor change at VP Marketing.
- A second team starts running developer events without an interlock.
- Docs stays at bus factor one for another quarter.
- Team reaches eight people.
- The sales interlock exceeds its four-hour cap for three consecutive weeks.
## Transition
- Week 1: publish this brief; Advocate A stops answering Discord ad hoc, and a triage rota covers it until the hire.
- Month 1: open the community req with the coverage map attached; start the roadmap slot.
- Quarter 1: draft the ladder criteria; re-check the docs backup risk.
- Unchanged: reporting line, docs ownership, refused education scope.
---
## Weak versus strong, on the contested sections
**Work inventory**
- Weak: "The team owns docs, content, community and events." A list of nouns re-assigns work nobody can trace back to a person.
- Strong: the table above - a named owner, their manager, real hours, and what breaks if the surface stops. It is the only section that survives contact with the people already doing the work.
**Reporting line**
- Weak: "DevRel will report to marketing, which is where it fits best given our go-to-market motion."
- Strong: the version above - driver, leader, starved pillar, named cover, review date. The weak one cannot be checked later, so nobody notices when the product loop dies.
**Shape**
- Weak: "We will move to a hub-and-spoke model with embedded advocates per squad."
- Strong: "Centralized at four people. Hub-and-spoke rejected: it needs a hub of two plus two spokes, which is six of our four heads. Revisit at eight."
**Coverage**
- Weak: "Community is a priority this year."
- Strong: "Community management: unowned since February. Median Discord first response is 4 days. Covered by a triage rota until the hire lands."
**Roles**
- Weak: "One advocate per two product lines is the industry ratio."
- Strong: "Two advocates cover six surfaces at 70% capacity - a planning baseline we chose, not a benchmark. Advocate-per-product-line ratios in circulation are single-company anecdotes; this headcount comes from the surface table above."
**Interlocks**
- Weak: "DevRel will partner closely with product, support and sales." Three permanent collaborations with no arbiter, which reads as availability rather than a boundary.
- Strong: the five lines above - one mode per team, what crosses, a named arbiter, and a cap in hours where the load is known to grow.
**Re-org triggers**
- Weak: "We will revisit the structure annually." A date nobody watches, and no way to tell early that the design has stopped fitting.
- Strong: observable conditions - sponsor change, a second team running events without an interlock, docs at bus factor one for another quarter. Each one is visible without a survey.
references/reporting-line-tradeoffs.md›
# Reporting line trade-offs
## Where DevRel actually reports
_State of Developer Relations 2024_ (11th annual survey, administered by DevRel.Agency; 310 valid respondents, 242 completions, 33 countries):
| Reports to | Share | Movement |
| ----------- | ----- | ------------------------- |
| Marketing | 33.1% | flat, still the plurality |
| Product | 21.7% | - |
| CEO | 20.3% | up from 14.1% |
| Engineering | 19.9% | - |
| Sales | 3.2% | up from 1.8% |
Supporting figures from the same survey, useful when a stakeholder asks what other companies do:
- 43.6% have more than one team performing DevRel activities, up from 33% the year before.
- 69% of teams are under ten people; 2-5 people is the most common band (35.2%); solo practitioners are 18.2%.
- 60% of program budgets exclude DevRel staff salaries; 26% include salaries for all DevRel roles.
- Weekly collaboration: product 39%, engineering 39%, marketing 35%, support 27%, customer success 25%, sales 23%, C-level 20%. Around 85% collaborate with product, marketing and engineering at least monthly.
No line has a majority. Treat anyone who claims DevRel "belongs" under one function as describing their own company, not the field.
## Per-line analysis
Each line's gravity comes from the metrics its leader is judged on. That is what predicts the drift, not the org chart.
### Marketing
- **Optimizes** reach, distribution, launch alignment, campaign integration, and budget defence - marketing leaders already know how to argue for spend.
- **Starves** the product feedback loop and, over time, technical credibility.
- **Characteristic failure** advocates absorbed into pipeline support: webinars, gated assets, lead targets. The audience reads the output as marketing and discounts it.
- **Counter-move** a written product interlock with a standing roadmap slot, plus a rule that no DevRel surface carries a lead-gen gate.
- **Wrong when** the funded driver is product input or enablement depth.
### Product
- **Optimizes** the feedback loop, roadmap influence, enablement depth, and proximity to what developers actually hit.
- **Starves** awareness spend and distribution muscle; product orgs rarely hold a promotion budget.
- **Characteristic failure** excellent material nobody discovers, and advocates absorbed into unpaid product management.
- **Counter-move** a named distribution partner in marketing with an agreed share of the channel calendar.
- **Wrong when** the company's problem is that nobody has heard of the product.
### Engineering
- **Optimizes** technical depth, credibility with the audience, and code-level artefacts - SDKs, samples, integrations.
- **Starves** narrative, measurement literacy and budget defence.
- **Characteristic failure** the team used as overflow engineering capacity; at review time it cannot explain its value in the language the funder uses.
- **Counter-move** a measurement interlock with marketing or a finance partner, and an explicit ban on DevRel absorbing feature work.
- **Wrong when** the program has to justify itself to a non-technical exec next quarter.
### CEO or founder
- **Optimizes** mandate, cross-functional access, and freedom from another function's metrics. Its rise (14.1% to 20.3%) tracks founder-led developer products.
- **Starves** operational support, career ladder, peer review, and everyday prioritization.
- **Characteristic failure** the line survives exactly as long as the founder's attention; the team has no manager who knows how to grow the discipline.
- **Counter-move** attach a re-decision date and name the function the team moves to when it crosses five people.
- **Wrong when** the founder is not personally engaged with developers week to week.
### Sales
- **Optimizes** attribution speed and pipeline visibility. It is the rarest line (3.2%) for a reason.
- **Starves** trust, community, and any work with a horizon longer than the quarter.
- **Characteristic failure** advocates become pre-sales engineers; the community reads the program as a sales channel and disengages.
- **Counter-move** if the driver genuinely is sales enablement, place the team in product or marketing and give sales a service interlock instead of the reporting line.
- **Wrong when** the audience includes anyone the company is not currently selling to - which is most of it.
## Decision rule
1. Name the funded driver and the leader who owns it.
2. Choose that leader's line, unless a political constraint from the interview blocks it.
3. Name the pillar that line starves, and the person or team covering it.
4. Set a review date, and treat a sponsor change as an automatic trigger to re-run steps 1-3.
## Split lines
Two teams under different parents is a real option, not a failure state. Documented example at Couchbase (Hoopy/Common Room job-titles report, Matthew Revell and Suze Shardlow, May 2023):
- Developer advocacy team: sits in the product organisation, producing integrations and supporting educational material.
- Developer relations team: sits in marketing, driving awareness and adoption.
A split buys depth on both sides. It costs a coordination surface and creates a shared-voice problem - two teams speaking to the same audience with different managers, metrics and calendars. Take it only when both halves clear their own staffing floor and one named person owns the shared voice.
references/sourced-numbers.md›
# Sourced numbers, chosen baselines, and refusals
Every number this skill uses is quotable, a chosen baseline, or refused. Say which, every time you put one in a brief. A chosen baseline presented as an industry standard is the fastest way to lose an org-design argument with a finance partner.
## Quotable, with attribution
All survey figures below come from _State of Developer Relations 2024_ (11th annual edition), administered by DevRel.Agency, 310 valid respondents, 242 completions, 33 countries, 58 questions, published at `stateofdeveloperrelations.com/2024devrelreport`. It is still the latest edition, so these figures are two budget cycles old - quote them with the year attached.
| Figure | Value | Use it to |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------- |
| Reporting line spread | marketing 33.1%, product 21.7%, CEO 20.3%, engineering 19.9%, sales 3.2% | prove no line holds a majority, so placement is a trade-off |
| CEO line movement | 20.3%, up from 14.1% | show the founder-led line is growing, not a curiosity |
| More than one team doing DevRel work | 43.6%, up from 33% | name fragmentation as the default starting condition |
| Team size | 2-5 people 35.2% (most common), solo 18.2%, under ten 69% | reality-check a shape copied from a large company |
| Functions staffed | advocacy 82.2%, community 52.7%, technical writing 42.7%, developer marketing 37.7%, developer education 35.6%, DX engineering 27.4% | show coverage is normally partial and hats are shared |
| Program budgets excluding salaries | 60% (26% include salaries for all roles) | force the "does this number include people?" question |
| Weekly collaboration | product 39%, engineering 39%, marketing 35%, support 27%, customer success 25%, sales 23%, C-level 20% | budget the real interrupt load before declaring interlock modes |
Non-survey sources this skill quotes:
- Conway's Law framing and the Couchbase split example - Hoopy / Common Room, _A review of DevRel job titles and career progression_, Matthew Revell and Suze Shardlow, May 2023.
- Collaboration / X-as-a-Service / Facilitation definitions and the cognitive-load principle - Team Topologies, Matthew Skelton and Manuel Pais, `teamtopologies.com/key-concepts`.
- Awareness → enablement → engagement responsibility split - Mary Thengvall, "The DevRel Path to Success", marythengvall.com, 9 March 2021.
- The scaling test - Phil Leggetter, "How to seed, grow and scale developer relations", leggetter.co.uk, 2021: "You're only really scaling a team if further investment increases output more than the increase in input."
- Levelling and the "head of" ambiguity - Kim Maida, "Forging your career in DevRel: Advocate to Exec", DevRelCon 2021.
## This skill's chosen baselines
Defensible starting points, consistent with the rest of this collection, and **chosen rather than measured**. Present each as a number the reader may move, never as a standard.
| Baseline | Value | Why this number |
| ---------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Capacity committed to planned work | at most 70% of declared capacity | leaves room for support load, launches and travel, which the survey's weekly-collaboration figures show is a real and recurring draw |
| Shape threshold | under roughly ten full-time people, centralized only | every other shape spends headcount on coordination; 69% of teams are under ten, so this is the common case, not the exception |
| Surface staffing floor | one accountable owner plus one named backup per surface | a bus factor of one is an outage waiting for a resignation |
| Reporting-line review | a dated review, plus an automatic re-run when the sponsor changes | the survey shows placement moves; the interval is yours to set |
| Interlock cap | one interaction mode per adjacent team | more than one mode per team means nobody can say what the boundary is |
## Numbers to refuse, and what to do instead
Refusing a number is a finding, not an oversight. Fill each with a derivation you show, never with a figure you invent.
- **Headcount ratios.** Every circulating ratio of advocates to developers, product lines, regions or engineers is a single-company anecdote rather than a measured standard. Derive staffing from the surface inventory, and say in the brief that that is what you did.
- **Levelled maturity models.** The Developer Relations Foundation (hosted by the Linux Foundation) states the intent to provide canonical definitions of DevRel structure and organization, and its published material is definitional rather than levelled. Cite it as the field's vendor-neutral body, never as a levelled model, and never invent levels for it.
- **Compensation bands.** DevRel roles are thin in salary-banding datasets, so a band quoted into a brief is guesswork wearing a decimal point. Send the user to live market data instead, and keep compensation out of the org design brief entirely.
## General management numbers - sanity checks only
Generic org-planning and capacity-planning tooling circulates figures like:
- Span of control: 5-8 direct reports.
- IC-to-manager ratio: between 6:1 and 10:1.
- Utilization targets: 75-80% for ICs, 60-70% for managers, 50-60% for interrupt-driven roles.
None is specific to DevRel, and each circulates as convention rather than measurement.
Use them one way only: as a sanity check when a proposed shape adds a management layer. A hub-and-spoke design that gives a hub lead two reports, or a centralized team that gives one manager fourteen, is worth questioning - but say in the brief that the check comes from general management practice, not from DevRel data. The interrupt-driven utilization row is also the closest external echo of the 70% baseline above - an echo, not a source, since it is convention in exactly the same way.
references/team-shapes-and-interlocks.md›
# Team shapes and interlocks
## Contents
- Per-shape worked examples and guards
- Interlock modes and how to write them down
- Per-team interlock defaults
## Per-shape worked examples and guards
The shapes, their staffing floors and the order they are chosen in are in step 3 of `SKILL.md`. What follows is only the material that does not fit beside the choice.
**Split by focus.** Documented example at Couchbase (Hoopy/Common Room, _A review of DevRel job titles and career progression_, May 2023):
- Developer advocacy team: sits in the product organisation, producing integrations and educational material.
- Developer relations team: sits in marketing, driving awareness and adoption.
Guard: name one person accountable for the shared voice, and one shared planning ritual, before approving the split.
**Hub-and-spoke.** The published scale-stage spokes are either functional teams (developer experience, education, community, integrations) or multi-functional regional teams - in both cases with specialization made explicit and decision authority pushed down to the spoke. Guard: the hub enables; it does not approve. A hub with an approval queue is a bottleneck wearing a standards label.
**Embedded.** Guard: the craft owner outside the host teams needs real time for the role, not a line in someone's job description, and the promotion criteria each advocate will be levelled against have to be written down before the first advocate moves.
Two checks apply to whichever shape is chosen:
- **Staffing.** Every proposed unit must be able to staff its own floor, including a backup for each surface it owns, or the shape is aspirational.
- **Conway's Law**, the sanity check the same job-titles report puts at the front of the question: the structure of a team imprints on the work it does.
- A team split by product line produces per-product content and no cross-product story.
- A team split by channel produces channel metrics and no journey.
Decide which imprint you want.
## Interlock modes
Borrowed from Team Topologies (Matthew Skelton and Manuel Pais). Each adjacent team gets exactly one mode, because the mode is a statement about how much of the other team's attention this consumes.
| Mode | Definition | Bandwidth | Fits |
| -------------- | ------------------------------------------------------------ | ---------------- | ---------------------------------------------------------------- |
| Collaboration | working together for a defined period to discover new things | high, time-boxed | launches, a new SDK, a first community venue |
| X-as-a-service | one team provides, one consumes, through a clear interface | low, ongoing | docs requests, review queues, event support, sample-app requests |
| Facilitation | one team helps and mentors another | medium, decaying | teaching engineers to write, spinning up a champions program |
Two rules make the modes useful rather than decorative:
- Collaboration must have an end date, or it silently becomes the operating model and the team turns interrupt-driven.
- Team Topologies' cognitive-load principle applies directly: adding an interlock without removing one is the standard way a small team stops being good at anything.
Write each interlock as one line:
`<team> - <mode> - <what crosses the boundary> - <who arbitrates when it stalls>`
The arbitration column is the one people skip and the one that gets used.
## Per-team interlock defaults
Defaults, not rules - override them when the inventory says otherwise.
| Adjacent team | Usual mode | What crosses | Common failure |
| ------------------------ | ---------------------------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------------- |
| Product | collaboration during launches, X-as-a-service otherwise | developer feedback in, roadmap and launch dates out | permanent collaboration; DevRel becomes unpaid product management |
| Engineering | facilitation | technical review in, writing and demo coaching out | DevRel absorbed as overflow engineering capacity |
| Docs / technical writing | X-as-a-service, either direction | drafts, reviews, structure decisions | ownership left implicit, so gaps appear exactly between the two teams |
| Support | X-as-a-service | recurring failure signals in, troubleshooting content out | DevRel used as an escalation tier |
| Developer marketing | collaboration on campaigns, X-as-a-service on distribution | content in, channels and audience data out | the credibility surfaces get campaign-ified |
| Sales | X-as-a-service, strictly | evaluation material out, field objections in | advocates booked as pre-sales engineers |
| Customer success | X-as-a-service | adoption blockers in, enablement material out | one-off customer requests crowding out reusable work |
Technical writing deserves the most attention: it is present on 42.7% of DevRel teams and sits under another manager in most of the rest, which makes it the single most common place for work to fall between two orgs.
SKILL.md›
---
name: devrel-team-structure
description: Designs the developer relations org - which function DevRel reports to (marketing, product, engineering, CEO, sales) and what that line starves, the shape (centralized, split, embedded, hub-and-spoke), the coverage map across advocacy, community, docs and education, the interlocks with product, docs, support and sales, and the trigger for the next re-org. Use whenever someone asks where DevRel should sit, who DevRel should report to, how to structure or restructure a devrel team, which devrel roles to staff at this size, whether to embed advocates in product teams, why devrel keeps getting pulled into other teams' work, or how devrel and docs divide ownership - even if they only say the team feels wrong. Not the budget split - use samber/developer-relations-skills@devrel-budget-allocation.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# DevRel Team Structure
You are a developer relations org designer. You decide, with the person accountable for the function, which parent it reports to, what shape it takes, which functions it covers, how it interlocks with the teams around it, and what would force the next re-org.
The output is a **DevRel org design brief**: a short document a VP can approve and a new hire can read to learn who owns what. You produce the structure, never the job postings, the interview loop, or the work itself - see samber/developer-relations-skills@devrel-hiring for those, once this brief has decided which seats exist.
Two facts, from the 2024 _State of Developer Relations_ survey (DevRel.Agency, 310 respondents), shape every recommendation. Check whether a newer edition has since published before quoting either one, and keep whichever year you cite attached to the figure.
- No reporting line holds a majority: marketing 33.1%, product 21.7%, CEO 20.3%, engineering 19.9%, sales 3.2%. Placement is a trade-off, never a best practice.
- 43.6% of respondents already have more than one team doing DevRel work, so you are almost always redrawing boundaries around existing owners rather than designing on a blank page.
## Interview
Ask one question at a time, multiple-choice where you can. Stop as soon as you can name the funded driver, the headcount and the existing owners - confirm the rest as you go.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. How many people do DevRel work today, and how many of those are full-time on it?
2. Which functions are covered today, even partly: advocacy, community, technical writing, developer marketing, developer education, developer-experience engineering?
3. Who does each of those report to right now? Name the manager, not the team.
4. Why is the company funding this: developer adoption, sales enablement, developer enablement, product input, ecosystem, contributor community, or employer brand?
5. Is the developer the user, the buyer, both, or neither?
6. How many product lines, SDK languages, regions and communities does the team currently serve?
7. What triggered this question - a new hire, a re-org, a leader leaving, a budget review, or work falling through the cracks?
8. Which work keeps landing on the team that nobody planned for?
9. Who owns the headcount budget, and who owns the program budget? They are often different people.
10. What is politically fixed - a line that cannot change, a manager who cannot be moved, a title convention the company enforces?
11. By when does the new structure have to be in place, and what drives that date - a hire, a re-org window, a board review?
12. Do you want a one-off fix to the pain you have now, or a structure that compounds as the company grows?
13. What is the effort ceiling - how much new headcount, how many hours per week of cross-team coordination, and how much political capital you can spend on a change you may have to undo?
Answers 11 to 13 re-rank the shapes in step 3, and you say which answer moved which shape: a hard near date promotes centralized, a compounding mandate promotes hub-and-spoke, a ceiling stated in headcount deletes every shape whose staffing floor sits above it, and a refusal to spend political capital deletes embedded.
Record the answers. If your harness has persistent memory, store the funded driver, the current owners map and the reporting line there - the next re-org conversation starts from this same inventory, and re-deriving it is where boundary arguments restart.
## Invocation examples
The first move is always the interview, then the work inventory - never a chart. Each example below names only the decision it turns on. The numbered steps handle the rest.
- _"Should DevRel report to marketing or product?"_ - refuse to answer until the funded driver has a named owner.
- _"We're going from 3 to 9 people next year - how should we structure the team?"_ - under ten people the answer is centralized, so the real work is the coverage map and the surfaces you will refuse.
- _"Should each product squad get its own advocate?"_ - test the embedded shape against its staffing floor and its ladder consequence.
- _"DevRel and docs keep fighting over ownership."_ - produce the two interlock lines and the arbiter, not a re-org.
- _"How many advocates should we have for 50,000 developers?"_ - refuse the ratio and derive the number from the surface inventory.
The deliverable is always the same artefact: a DevRel org design brief, sections as listed in step 7, agreed one section at a time.
## Label every number
Every number you write is sourced, self-set, or refused, and the reader must always know which:
- Quote a sourced figure with its source and year.
- Label a self-set baseline as this skill's own and adjustable.
- Refuse headcount ratios and compensation bands outright, since every figure in circulation for either is a single-company anecdote.
The full sorting, including general-management figures usable only as sanity checks, is in [references/sourced-numbers.md](./references/sourced-numbers.md).
## Step 1 - Inventory the work before drawing any chart
List every recurring DevRel surface the company has committed to: docs set, quickstart, blog, community venue, event calendar, SDK set, sample apps, champions cohort, changelog, support presence, OSS repos.
For each surface, record four columns:
- Owner today (a person).
- Their manager.
- Hours per week it really takes.
- What happens if it stops.
Mark each as owned, shared, unowned, or informally absorbed by someone with a different job title.
Refuse to propose a structure until this table exists. Every re-org that skips it re-assigns work that was already being done by someone invisible, and that person stops doing it the day the chart changes.
## Step 2 - Choose the reporting line
Pick the line whose leader owns the funded driver from question 4:
- Adoption and awareness drivers point to marketing.
- Product-input and enablement drivers point to product or engineering.
- Sales enablement points to product or marketing with a sales interlock, not to sales.
- A founder-led program with no other credible sponsor points to the CEO, with a re-decision date attached.
Every line optimizes something and starves something else. Load [references/reporting-line-tradeoffs.md](./references/reporting-line-tradeoffs.md) for the per-line table: what it optimizes, what it starves, its characteristic failure, the counter-move, and the conditions under which it is wrong.
State the choice in this shape, and require all four parts:
> DevRel reports to `<function>`, because the funded driver is `<driver>` and `<leader>` owns it. This line will starve `<pillar>`. `<named person or team>` covers that gap, reviewed at `<date>`.
A line chosen without naming what it starves fails silently: nobody notices the missing pillar until the annual review, when it is described as a performance problem instead of a structural one.
## Step 3 - Choose the team shape
Four shapes are in circulation, ordered here by value per unit of effort. Effort is standing headcount, the coordination the shape adds across teams every week, and how hard it is to undo once people have been re-managed - never a salary figure.
- efficiency: `centralized > hub-and-spoke > split by focus > embedded`
- value, as roadmap proximity and product feedback bought: `embedded > hub-and-spoke > split by focus > centralized`
- effort, as standing headcount plus coordination plus reversibility: `embedded > split by focus > hub-and-spoke > centralized`
The orders disagree on purpose: the shape that produces the best product feedback is also the one that costs the most and undoes the worst.
1. **Centralized** - one team, one manager, one budget, serving everything.
- Floor: one person, near-zero added coordination, reversible in a week.
- Buys: a shared calendar, a shared voice, one place to say no.
- Costs: distance from each product line, and a request queue once internal customers outnumber what one manager can prioritize.
2. **Hub-and-spoke** - a small hub owns craft, standards, tooling and calendar; spokes execute close to a product line or region.
- Floor: a hub of two to three plus at least two spokes, a management layer and a standing forum, a quarter to stand up and a quarter to unwind.
- Buys: consistency with locality.
- Costs: a bottleneck the moment the hub starts approving work instead of enabling it.
3. **Split by focus** - two teams under different parents, divided by what the work is for.
- Floor: roughly eight, because each half needs a viable team; coordination is permanent rather than setup, and unwinding it needs two leaders to agree to give up a team.
- Buys: real depth on enablement and on awareness at once.
- Costs: a shared-voice problem - two teams, one audience, two calendars, two metric sets.
4. **Embedded** - advocates report into product, engineering or regional teams.
- Floor: one advocate per host team plus a craft owner somewhere; coordination is a standing job, and it is the least reversible shape, because each advocate is levelled and promoted by a host manager who now owns that headcount.
- Buys: the best product feedback available - the advocate hears what the team hears.
- Costs: the shared craft, the shared calendar, usually the career ladder.
**What this order starves: embedded.** It is last on efficiency in every ordinary case and first on the one thing DevRel is most often funded to produce.
Promote it anyway when all four hold:
- The funded driver from question 4 is product input.
- The product lines have genuinely different audiences.
- Each host team can fund _and_ level the role.
- A named craft owner survives outside the host teams.
Missing any one of the four, embedded buys feedback with nothing left to turn it into work.
Delete the shapes the answers rule out instead of demoting them, and say which you deleted. Under roughly ten full-time people, split, embedded, and hub-and-spoke are all gone, and centralized is the only candidate left. That ten-person line is this skill's baseline, not a published finding. What the survey supports is the context: 69% of teams are under ten people, so every other shape spends headcount on coordination the common case does not have. A ruled-out shape parked at the bottom of a list reappears as scope a quarter later.
The ordering is a default, not a law: it shifts with context and with who executes it. Re-rank it against what you already know:
- An advocate a host team already funds and levels has pre-paid embedded's effort for that product line.
- A politically fixed line from question 10 deletes whichever shape needs it moved.
- Answers 11 to 13 re-rank it too.
Test any shape that adds people or a management layer against Phil Leggetter's scaling test (leggetter.co.uk, 2021): "You're only really scaling a team if further investment increases output more than the increase in input." A shape that turns two extra hires into two extra people's worth of output has bought nothing but coordination.
Before recommending one, say explicitly that you are in brainstorming mode and build **two or three whole candidate structures** - each one a line, a shape and a coverage split together, since those three choices only make sense as a set. Give each candidate:
- What it makes easy, and what it makes hard.
- The headcount it assumes.
- The weekly coordination it adds, and what undoing it would take.
- The first thing that would break.
- The conditions under which it is the wrong pick.
Order the candidates by efficiency, recommend one, say why, and let the accountable person choose before you detail anything below it. A structure decided in one pass gets re-litigated for a year; a structure chosen against two rejected alternatives holds.
Read [references/team-shapes-and-interlocks.md](./references/team-shapes-and-interlocks.md) for the worked examples and the per-shape guard once a shape is chosen. Sanity-check it against Conway's Law, which the Hoopy/Common Room job-titles report (Revell and Shardlow, May 2023) puts at the front of the same question: the structure of a DevRel team imprints on the work it does.
- A team split by product line produces per-product content and no cross-product story.
- A team split by channel produces channel metrics and no journey.
## Step 4 - Set coverage first, headcount second
For each of the six functions, mark one of these states: owned by this team, owned by another named team, shared with a named split, unowned, or deliberately refused.
- Advocacy
- Community management
- Technical writing
- Developer marketing
- Developer education
- Developer-experience engineering
The survey's coverage shares are the reality check on that map (_State of Developer Relations 2024_):
| Function | Staffed on |
| -------------------------------- | ----------------------- |
| Advocacy | 82.2% of surveyed teams |
| Community management | 52.7% |
| Technical writing | 42.7% |
| Developer marketing | 37.7% |
| Developer education | 35.6% |
| Developer-experience engineering | 27.4% |
Partial coverage is the norm, so record an unowned function as a decision, never hide it as an embarrassment.
Convert coverage into people only after that map is complete. Two baselines do most of the work - both are this skill's, not benchmarks:
- Every surface needs one accountable owner and one named backup. A surface with a bus factor of one is an outage waiting for a resignation.
- Plan against at most 70% of declared capacity. Support load, launches and travel take the rest, and a plan that assumes 100% converts into unplanned overtime within a quarter.
A gap on the map has four resolutions, not one:
- Hire.
- Re-scope onto an existing owner.
- Refuse the surface in writing.
- Contract it out. Contracting is a program-strategy call - see `samber/developer-relations-skills@devrel-strategy` - but the org consequence is yours: a contracted surface still needs one internal accountable owner, or it disappears the day the contract ends.
For the split of responsibilities across the three core roles, use Mary Thengvall's awareness → enablement → engagement mapping ("The DevRel Path to Success", 2021):
- Advocates own awareness.
- Developer experience owns enablement.
- Community management owns engagement.
It is the cleanest published division, and it survives being applied internally, to colleagues, as well as externally.
Refuse to state a headcount ratio as a benchmark. Every circulating ratio of advocates to developers, product lines or engineers is a single-company anecdote rather than a measured standard. Derive the number from the surface table in step 1 instead, and say that is what you did.
**Audience changes the mix:**
- Individual-developer adoption pulls advocacy, community and content weight.
- Company or enterprise adoption pulls enablement, developer-experience engineering and technical writing, because the artefacts an approver reads are documents, not talks.
Most programs face both - rank them for this horizon instead of splitting evenly. Consumer-marketing org patterns do not transfer here: a developer audience evaluates the artefact, never the campaign.
## Step 5 - Define the interlocks
An org chart without interlocks just relocates the arguments. For each adjacent team - product, engineering, docs/technical writing, support, developer marketing, sales, customer success - declare one interaction mode, borrowed from Team Topologies (Skelton and Pais):
- **Collaboration** - working together for a defined period to discover something new. High bandwidth, time-boxed. Right for a launch or a new SDK.
- **X-as-a-service** - one team provides, the other consumes, through a clear interface. Right for docs requests, review queues, event support.
- **Facilitation** - one team mentors the other. Right for teaching engineers to write, or running a champions program.
One mode per adjacent team is this skill's rule, not Team Topologies': more than one mode means nobody can say what the boundary is.
Collaboration is the expensive mode. A team in permanent collaboration mode with product, marketing, support and sales at once is not integrated; it is interrupt-driven. The interrupt load is already real: 39% of surveyed teams collaborate weekly with product, and 39% with engineering.
Write each interlock as one line: `<team> - <mode> - <what crosses the boundary> - <who arbitrates when it stalls>`. The arbitration column is the one people skip and the one that gets used.
## Step 6 - Name the ladder and the budget owners
Say which career ladder the team's roles sit on: the engineering ladder, the marketing ladder, or a DevRel-specific one. A team on a borrowed ladder gets promoted against criteria that do not describe its work, which is a slow retention leak rather than a loud failure.
Check the title against the scope: if the top rung is a manager accountable for company-level goals, the role warrants a director's title and influence (Kim Maida, "Advocate to Exec", DevRelCon 2021). "Head of" is ambiguous both internally and on the market - resolve it to a real level.
If the shape adds a manager, sanity-check the span: a lead with two reports and a manager with fourteen are both worth questioning. Say the check comes from general management practice, because no DevRel-specific span data exists.
Record who owns the headcount budget and who owns the program budget separately. In 60% of surveyed programs, staff salaries sit outside the DevRel program budget, so the person who approves an event is often not the person who approves a hire. How the program budget gets split across pillars is a different decision - see `samber/developer-relations-skills@devrel-budget-allocation`.
## Step 7 - Write the brief, validated section by section
```markdown
# DevRel org design brief - <company>, <date>
## Situation what triggered this, and the funded driver
## Work inventory surfaces × owner today × hours × what breaks if it stops
## Reporting line the line, why, what it starves, who covers that, review date
## Shape centralized / split / embedded / hub-and-spoke, and the coordination it buys
## Coverage six functions × owned / other team / shared / unowned / refused
## Roles per person: surfaces owned, backup, capacity assumption
## Interlocks team × mode × what crosses × who arbitrates
## Ladder & titles which ladder, level mapping, title corrections
## Budget headcount owner, program owner
## Re-org triggers the observable conditions that force the next redesign
## Transition what changes in week 1, month 1, quarter 1, and what stays
```
Attach each number's label as you write it - a source and a year, or "our baseline, adjustable" - rather than in a cleanup pass at the end. A reader must never have to guess which kind of number they are looking at.
Present one section at a time and get agreement before writing the next. Catching a wrong reporting line at section three costs a paragraph. Catching it at section eleven costs the document.
A full worked brief, with weak and strong versions of the contested sections, is in [references/org-design-brief-example.md](./references/org-design-brief-example.md).
## Re-org triggers
Close the brief with the conditions that should reopen it, written as observations rather than dates:
- The funded driver changes, or the sponsor who owns it leaves.
- A second team starts doing DevRel work without a declared interlock.
- Any surface loses its backup and stays at a bus factor of one for a quarter.
- The team declines the same category of request three times for lack of coverage.
- Headcount crosses the ten-person line, where shapes other than centralized become affordable.
- An interlock stays in collaboration mode past the end of the thing it was created for.
Naming the triggers up front converts the next re-org from a political event into a scheduled one.
## Quality gate
Hold the brief to this threshold and iterate until it passes. Report the check explicitly at the end.
- The work inventory lists a named person per surface, including the surfaces the team does not own.
- The reporting line names a driver, a leader, a starved pillar and who covers it.
- The shape is justified by coordination it buys, not by what a larger company does, and the shapes the answers ruled out are deleted rather than listed at the bottom.
- Every one of the six functions has one of the five coverage states - none left blank.
- No surface has a bus factor of one without being flagged as a known risk.
- Every adjacent team has exactly one interaction mode and a named arbiter.
- Planned work fits inside 70% of stated capacity, and the brief says that ceiling is a chosen baseline.
- Every number carries either a source and a year, or an explicit "baseline, adjustable" label.
- No headcount ratio is quoted as a benchmark, and no compensation band appears at all.
- The re-org trigger list is non-empty and observable without a survey.
A brief that fails the capacity line does not have a discipline problem. It has one surface too many, and the fix is to move it, refuse it, or staff it.
## Common failure modes
- **Drawing the chart first.** The inventory is what makes the chart survive contact with the people already doing the work.
- **Copying a large company's shape.** Their hub-and-spoke presupposes spokes you cannot staff. Derive the shape from headcount and surfaces.
- **Reorganising instead of re-scoping.** A program missing its goal has usually funded too many surfaces, not chosen the wrong parent. Check the surface count before moving boxes.
- **Quoting a staffing ratio.** Numbers with no sample behind them survive one question from a finance partner.
- **Promoting a baseline to a standard.** "Teams plan to 70% capacity" invites a demand for the study. "We plan to 70% and here is why" invites a negotiation you can win.
- **Importing generic org benchmarks silently.** Span-of-control and utilization figures from general management tooling are usable as sanity checks, never as DevRel evidence - label them when you use them.
- **Leaving docs ownership implicit.** Technical writing is present on 42.7% of teams and sits elsewhere in most of the rest - say which, in writing.
- **Reporting to sales.** It buys fast attribution and costs the community's trust; the surveyed 3.2% is small for a reason.
- **A CEO line with no expiry.** It works while the founder's attention lasts, then leaves the team with no manager who knows how to grow the discipline.
- **Titles borrowed from another ladder.** Promotion criteria that do not describe the work push out the people who do it best.
- **One re-org per new leader.** Each redraw costs a quarter of interlock rebuilding; the trigger list exists to make that cost deliberate.
## References
- [references/reporting-line-tradeoffs.md](./references/reporting-line-tradeoffs.md) - per-line optimizes/starves/failure/counter-move table, survey benchmarks, and the decision rule.
- [references/team-shapes-and-interlocks.md](./references/team-shapes-and-interlocks.md) - per-shape worked examples and guards, plus the interlock matrix per adjacent team.
- [references/org-design-brief-example.md](./references/org-design-brief-example.md) - a full worked brief, with weak vs strong versions of the contested sections.
- [references/sourced-numbers.md](./references/sourced-numbers.md) - every figure sorted into quotable, chosen baseline, or refused, with sources and sample sizes.
Related skills in this collection:
- `samber/developer-relations-skills@devrel-strategy` - the program charter this structure serves.
- `samber/developer-relations-skills@devrel-budget-allocation` - splitting the program budget across pillars.
- `samber/developer-relations-skills@devrel-metrics` - what the team is measured on.
- `samber/developer-relations-skills@developer-segmentation` - the audience cut that changes the role mix.
- `samber/developer-relations-skills@devrel-career` - the individual's side of the ladder this brief defines.
- `samber/developer-relations-skills@devrel-hiring` - job postings, interview loops and ramp plans for the seats this brief creates.
See also `samber/developer-platform-skills` when the structure question is really a platform-team question.