devrel-team-structure

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.

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 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 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):

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

# 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

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.

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 - per-line optimizes/starves/failure/counter-move table, survey benchmarks, and the decision rule.
• 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 - a full worked brief, with weak vs strong versions of the contested sections.
• 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.