samber/developer-relations-skills已通过检查
SKILL DETAIL
devrel-budget-allocation
samber/developer-relations-skills/devrel-budget-allocation
Splits a developer relations budget across pillars - events, content, community, tooling, education, OSS sponsorship - into line items that each carry a cash cost, an hours cost, a pre-set return threshold, a review date and a reallocation rule, plus a ranked cut list. Use whenever someone asks how to plan or split a devrel budget, how much to spend on events versus content versus community, whether a line item is worth its money, how to defend a devrel budget at review, or what to cut first when the budget shrinks - even if they only say "we spend too much on conferences". Not the metrics framework (samber/developer-relations-skills@devrel-metrics) or one event's ROI (samber/developer-relations-skills@developer-event-sponsorship).
安装量 · 426查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill devrel-budget-allocation
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "devrel-budget-allocation",
"evals": [
{
"id": 1,
"prompt": "I run devrel at Halcyon Metrics, a Series A observability startup in Lisbon. I've got 180,000 EUR approved for next year and I need to split it. The team is me (about 25 hours a week on devrel after my support rotation), a technical writer at 30 hours a week, and a designer who gives us maybe 6 hours a week. Salaries sit on a separate headcount line our VP Marketing owns. Our funded driver is self-serve developer adoption. Last year we ran 3 conferences, published 14 blog posts, and started a Discord. Can you give me the split across events, content, community, docs and tooling, and education?",
"expected_output": "A budget allocation stating both a cash envelope and an hours envelope, money sorted into four buckets, concentration into at most two pillars with the starved pillar named, a reserve, per-line owners with cash and hours, an unfunded list, an ordered cut list, and a short funder narrative.",
"files": [],
"expectations": [
"States an hours envelope alongside the cash envelope, totalled from the three named people at 25, 30 and 6 hours per week.",
"Applies a deduction of between 20% and 30% to the hours envelope before planning against it, and gives the reason (support load, launches, incidents).",
"Sorts the money into committed, discretionary, borrowed and in-kind rather than treating all 180,000 EUR as allocatable.",
"States explicitly that the 180,000 EUR excludes staff salaries, and notes that this changes any comparison with other programs.",
"Funds at most two pillars above token level rather than splitting across all five pillars the user listed.",
"Names what the chosen concentration deliberately starves.",
"Holds between 10% and 20% of discretionary spend as an unallocated reserve.",
"Labels the reserve percentage as a self-set starting point rather than an industry standard.",
"Gives every funded line an owner who is one of the three named people, never 'the team' or 'devrel'.",
"Gives every funded line both a cash figure and an hours figure.",
"Flags any line whose hours exceed the hours envelope as unfunded regardless of its cash.",
"Produces both an unfunded list and an ordered cut list, and neither is empty.",
"Closes with a funder narrative of at most five sentences containing no devrel jargon.",
"Tags every percentage or threshold it states as sourced, program baseline, or self-set."
]
},
{
"id": 2,
"prompt": "Our CFO looked at next year's devrel plan and said 40% on events is way above industry norms and we should cut it to 15%. We're Brightforge, we sell an enterprise API gateway, deals are six figures and always involve a security architect plus a platform lead signing off before procurement. Budget is $420K excluding salaries. Who's right here, and what's the actual industry benchmark for event spend?",
"expected_output": "The published survey figure quoted with all its caveats and refused as a target, plus a decision made on Brightforge's own funded driver and enterprise buying motion.",
"files": [],
"expectations": [
"Names the published figure as a mean of 41.1% of program budget going to events, attributed to a named 2024 developer relations survey.",
"States the sample size of n=47 for that allocation-split question.",
"States that the published shares sum to more than 100% (104.5%), so respondents answered on inconsistent bases.",
"States that the published category set omits community, tooling, education and OSS sponsorship, so a pillar allocation cannot be mapped onto it one-to-one.",
"Refuses to present 41.1% as a correct or target event share.",
"States that roughly 60% of surveyed program budgets exclude salaries, so the published split and Brightforge's $420K are not directly comparable.",
"Decides the question on Brightforge's funded driver and adoption motion rather than on the survey figure.",
"Identifies Brightforge's motion as company or enterprise buying, using the six-figure deals and the named approvers as the evidence.",
"States that an enterprise buying motion promotes field-and-events to the top of both the value and the efficiency ordering.",
"Does not invent any figure for devrel spend as a share of revenue or of marketing spend.",
"Tags the 41.1% figure as sourced, and keeps it distinct from any self-set number it proposes.",
"Recommends a defensible event share for Brightforge without describing that share as an industry norm."
]
},
{
"id": 3,
"prompt": "Finance just told me to take 20% out of devrel by Friday, and they've hinted a 40% scenario might follow. Current year at Northwind Data, $300K discretionary: conference booths $90K, agency content pipeline $70K, docs and samples maintenance $55K, Discord community plus champions $40K, OSS sponsorships $25K, newsletter sponsorships $20K. The docs line is what keeps four SDK sample repos green in CI. I've defended the agency content pipeline at two consecutive reviews as our long-game bet. What should I cut?",
"expected_output": "Two ordered cut scenarios (20% and 40%), each removal carrying a one-sentence consequence, rented reach going first, the actively-decaying docs line protected, and the twice-protected compounding line held back from being cut first.",
"files": [],
"expectations": [
"Produces an ordered cut list rather than a flat percentage trim applied to every line.",
"Builds both a 20% and a 40% scenario, with the 40% scenario containing the 20% removals.",
"Attaches a one-sentence consequence to every removal.",
"Cuts rented reach first, taking newsletter sponsorships and sponsorship depth before compounding or foundational lines.",
"Protects the docs and SDK sample maintenance line, cutting it last or not at all.",
"Justifies protecting that line because its neglect is actively wrong (broken samples, stale docs) rather than merely invisible.",
"States that the cut order is the efficiency ordering read from the bottom, not a ranking by cash size.",
"Does not rank the pillars against each other by cost per outcome unit anywhere in the answer.",
"Does not put the agency content pipeline first on the chopping block, on the grounds that a compounding line protected across two periods cannot be the first thing dropped.",
"Warns that a team volunteering no order gets a flat percentage applied to every line, which starves compounding work first.",
"Notes that roughly a quarter of surveyed programs lost budget in a single year, so a cut is a normal planning case rather than a crisis.",
"States which lines must be protected, not only which lines go.",
"Names what capability is lost in the 40% scenario, not only the dollar amount removed."
]
},
{
"id": 4,
"prompt": "Honest question: I've asked three times and nobody will tell me what our devrel budget actually is. I'm at Verdanix, about 120 people, B2B data pipeline tooling. My manager says 'just tell me what you need' and finance says 'ask your manager'. I need to plan Q1 through Q4. Do I just guess a number and build the plan around it?",
"expected_output": "Reframes the missing number as the majority case, switches the deliverable to a list of questions with owners and dates plus a percentage-based provisional split, and still states an hours envelope.",
"files": [],
"expectations": [
"Tells the user this is the majority case, citing that about a third of surveyed practitioners cannot state their budget and roughly another sixth have no set budget at all.",
"Refuses to invent a currency figure for Verdanix's budget.",
"Does not produce a benchmark budget derived from headcount, revenue or company stage.",
"Switches the deliverable to a list of questions that must get answered, each with a named owner to ask and a date to get it by.",
"Produces a provisional allocation expressed in percentages rather than in currency.",
"States that the percentage split survives whatever absolute number eventually comes back.",
"Asks whether the number, when it arrives, includes staff salaries.",
"Asks who signs the budget off and when the cycle locks.",
"Asks what is already committed under contract and for how long.",
"Still states an hours envelope, because capacity is knowable even when cash is not.",
"Notes that the reporting line usually determines who signs the budget, and that no single reporting line holds a majority in the published survey."
]
},
{
"id": 5,
"prompt": "Building the board deck for our devrel program at Caldera Systems. The board wants three numbers: what percentage of ARR we should be spending on developer relations, what our cost per developer reached should be, and what the normal headcount-to-budget ratio is for a devrel team at Series B. We're at $14M ARR, 3 devrel people, $260K program budget. Give me the benchmarks and where we land against them.",
"expected_output": "A refusal to supply any of the three benchmarks, an explanation that no quotable industry figure exists for them, the program's own prior period offered as the only legitimate baseline, and a defensible alternative for the deck.",
"files": [],
"expectations": [
"Refuses to state a benchmark for devrel spend as a percentage of ARR or revenue.",
"Refuses to state a benchmark for cost per developer reached.",
"Refuses to state a benchmark headcount-to-budget ratio.",
"States plainly that no quotable industry figure exists for these, rather than producing a plausible one.",
"Does not compute Caldera's own ratios and then present them as a comparison against an industry figure.",
"Offers the program's own prior period as the only legitimate baseline for each of the three numbers.",
"Where no prior-period baseline exists, proposes funding the line as an experiment with a fixed window and a kill date instead of a number.",
"Also refuses to supply a recommended split across community, tooling, education or sponsorship.",
"Offers the board deck an alternative it can defend, such as line-level thresholds derived from Caldera's own baseline.",
"Tags any number it does state as sourced, program baseline, or self-set.",
"Warns that a specific-sounding figure gets quoted back for years after the guess behind it is forgotten.",
"Does not describe any self-set figure it proposes as a standard or a benchmark."
]
},
{
"id": 6,
"prompt": "We're launching our v3 platform at Stilwater on March 14th, which is about ten weeks out, and I have $120K of unspent devrel budget that has to go out this fiscal year or we lose it. My shortlist: sign a content agency to run our blog, build a certification program for our partner integrators, buy three newsletter sponsorships, and refresh the quickstart. I want the launch to land loudly. What gets funded?",
"expected_output": "Lines whose latency runs past March 14 deleted on latency grounds with the published setup-cost and lead-time figures cited, rented reach promoted, the quickstart funded, and the deleted lines named with the constraint that removed them.",
"files": [],
"expectations": [
"Treats March 14 as the binding constraint on which lines can be funded at all.",
"Deletes the content agency line for this period on latency grounds rather than on cost grounds.",
"Cites roughly 8 to 9 weeks from concept to publication for an outsourced piece, attributed to a published account of an agency content pipeline.",
"Cites roughly six months of a director's own time to build that pipeline before it produced at volume.",
"Deletes the certification program because its build runs a quarter or more, past the launch date.",
"Promotes rented reach, specifically the newsletter sponsorships, because the result must land inside the period.",
"Funds the quickstart refresh, whose latency fits inside ten weeks.",
"Says which answer or constraint moved which line.",
"States that a budget which must be spent this period or is lost promotes rented reach and demotes anything whose first readable signal lands after the lock date.",
"States that paid distribution stops working the day it stops being paid, so it belongs in the campaign horizon and never in the compounding one.",
"Names the certification program's permanent recurring obligations, such as item security, cheating response and recertification cycles, if it is ever funded.",
"Puts the deleted lines on a named ruled-out list with the constraint that removed them, rather than at the bottom of a ranking."
]
},
{
"id": 7,
"prompt": "Aldergate went fully remote and our COO put a hard freeze on all conference travel. It's not a budget thing, it's policy, and it isn't lifting this year. I've got 95,000 GBP discretionary for devrel. I still want you to show me all the options ranked so I can see what we're giving up. Also, I'd love a certification program but there's no way we can staff it, our one advocate is already at capacity.",
"expected_output": "Field-and-events and the certification program deleted outright onto a ruled-out list with their constraints named, a separate unfunded list, and the remaining shapes ranked on effort axes with the starved option named.",
"files": [],
"expectations": [
"Deletes the field-and-events shape outright rather than ranking it last.",
"Names the travel policy as the constraint that removed field-and-events.",
"Puts field-and-events on a ruled-out list kept separate from the unfunded list.",
"Also rules out the certification program, naming the advocate's capacity ceiling as the constraint.",
"States that an effort ceiling below what a line needs deletes that line rather than demoting it.",
"Explains that a ruled-out line parked at the bottom of a ranking reappears as scope the next time the envelope moves.",
"States that a ruled-out line returns only if the constraint lifts, unlike an unfunded line.",
"Produces a non-empty unfunded list distinct from the ruled-out list, with one line each on what would have to change to fund it.",
"Ranks the remaining shapes against each other, not against the deleted one.",
"Ranks them on effort axes such as hours, setup latency and exit cost, never on cash.",
"Names what the resulting order starves and the condition that would promote it.",
"Does not propose working around the travel freeze with a smaller or cheaper event line."
]
},
{
"id": 8,
"prompt": "I pulled last year's numbers at Ravencourt and I want you to rank our pillars by ROI so I know what to fund. Events: $88K for 140 qualified conversations, so $629 each. Content: $54K for 22 published pieces, $2,454 a piece. Community: $31K and 1,840 answered questions, $17 each. Docs and samples: $46K, and honestly I can't put a number on it. Community is clearly the winner at $17 a unit. Should I move money out of content and events into community?",
"expected_output": "A refusal to rank pillars by cost per unit, the two legitimate cost-per-unit comparisons named, an effort-based ranking instead, the outcome-share versus budget-share comparison offered, and the unmeasured docs line treated as a visibility problem.",
"files": [],
"expectations": [
"Refuses to rank the four pillars against each other by cost per outcome unit.",
"States that the units measure different things, so the comparison is invalid rather than merely imprecise.",
"States that the pillar easiest to instrument wins such a ranking regardless of its actual value.",
"Names the two comparisons where cost per unit stays legitimate: the same pillar across periods, and the same pillar across options.",
"Refuses to recommend moving money into community on the strength of the $17 figure.",
"Ranks the pillars on effort instead, using hours, setup latency and exit cost, expressed in magnitudes.",
"Does not use a cash figure as the denominator of any ranking it produces.",
"Offers the outcome-share versus budget-share comparison as the legitimate cross-pillar adjustment, and explains that it works because it compares two ratios rather than two costs.",
"Says to fund up where outcome share exceeds budget share and the audience is still under-served.",
"Says to question any pillar whose budget share has outrun its outcome share for two consecutive periods.",
"Treats the docs line's missing number as a visibility problem rather than as evidence the line is weak.",
"Warns that growing spend on an outcome nobody can read buys a renewal argument, not a result.",
"Notes community's unusually high exit cost, where winding it down damages trust in a way a cancelled sponsorship does not, before recommending any increase."
]
},
{
"id": 9,
"prompt": "Let me lay out what I've got at Fenwick Labs for FY27. Total pot: $340K. That includes a three-year conference sponsorship we signed in 2025 at $48K a year with one year left and a 90-day notice clause, a community platform licence at $9K renewing in November, and about $60K that Demand Gen spends on developer dinners which our VP told me I can count as mine this year. Plus our staff engineers give us maybe 5 hours a week for reviews. So I've got $340K to play with. Where do I put it?",
"expected_output": "The $340K split into committed, discretionary, borrowed and in-kind, the signed contract treated as a renew-or-notice decision, the Demand Gen money attributed to its real owner and excluded from the discretionary total, and a notice-date reallocation trigger written.",
"files": [],
"expectations": [
"Separates the $340K into committed, discretionary, borrowed and in-kind rather than treating it as one allocatable figure.",
"Classifies the three-year conference sponsorship and the community platform licence as committed, not discretionary.",
"States the discretionary figure that is actually being allocated, net of the committed lines.",
"Treats the conference contract as a renew-or-notice decision keyed to its 90-day notice date, not as a line to re-justify mid-contract.",
"Records the November renewal date for the community platform licence as its own notice decision.",
"Classifies the $60K of Demand Gen spend as borrowed, names Demand Gen as its owner, and marks it as outside Fenwick's control.",
"States that no critical line may depend on the borrowed money.",
"Classifies the 5 hours a week of staff-engineer review as in-kind, with a hard ceiling and no invoice.",
"Warns that the other team re-planning can make a borrowed line vanish mid-period.",
"Notes that more than one team performing devrel work means a single program budget understates total company spend on the function.",
"Adds a reallocation trigger for the moment a committed contract reaches its notice date.",
"Does not include the borrowed $60K inside the discretionary total it then splits."
]
},
{
"id": 10,
"prompt": "Help me write the success criteria for next year's devrel lines at Sablecourt. My draft: Discord should hit 10,000 members, the blog should become the top Google result for 'event-driven architecture', conference booths should generate strong pipeline, and docs should just stay current. We've never really tracked any of this, our analytics only got set up in August and nobody owns the numbers. I want targets I can take to my VP.",
"expected_output": "Aspiration-derived targets rejected, baseline-less lines converted into experiments with kill dates, pillar-native outcome units assigned, the four-point readability score applied and failed, and affected lines held flat with the increment spent on visibility.",
"files": [],
"expectations": [
"Rejects thresholds derived from aspiration rather than from a baseline the program already has.",
"Points out that Sablecourt has no baseline for these lines, so most of them cannot carry a number yet.",
"Converts baseline-less lines into experiments with a fixed window and a written 'we will know X by date Y' statement instead of a number.",
"Rejects a raw Discord member count as an outcome unit, because joins can be bought without producing a single answered question.",
"Gives each pillar an outcome unit from that pillar's own vocabulary, such as cost per qualified conversation for events, cost per published-and-reviewed piece for content, and cost per answered question or active contributor for community.",
"Rejects 'stay current' and 'strong pipeline' as thresholds because they carry no unit and no number, so the line renews by default.",
"Scores the program 1 to 3 on each of four readability points: the outcome is instrumented at all, the instrumentation predates the spend, someone owns the number, and there is an agreed attribution story.",
"Notes that Sablecourt's instrumentation does not predate the spend and nobody owns the numbers, so the score falls below half marks.",
"Holds the affected lines flat and spends the increment on visibility first, rather than growing a line nobody can read.",
"Labels the four-point score and its cut-off as a self-set gate rather than an industry standard.",
"Frames every threshold as repeatable and cheap to apply rather than statistically rigorous.",
"Explains that a threshold defended as proof invites an attribution argument that devrel measurement cannot win.",
"Gives every line a review date and a written miss action, both set before the money is spent."
]
},
{
"id": 11,
"prompt": "Skip the process, I just need the numbers. Kessler Interactive, $250K devrel budget for next year, four-person team, we make a game engine SDK. Developers find us individually and start on the free tier, then their studios upgrade once a project ships. Give me the table with the percentages per pillar and I'll take it from there.",
"expected_output": "Explicit brainstorming mode with two or three whole-budget candidates rather than one table, each presented with six stated properties, a recommendation, a request for the shape to be agreed before pricing, and the motion identified as individual adoption.",
"files": [],
"expectations": [
"Does not hand over a single pillar percentage table on the first pass.",
"Says explicitly that it is in brainstorming mode before proposing anything.",
"Builds two or three whole-budget candidates rather than one.",
"Presents each candidate with the pillar it over-invests in, its three largest lines, what it deliberately starves, the hours it needs, the earliest signal it is working, and the conditions under which it is the wrong shape.",
"Recommends one candidate and says why.",
"Asks the budget owner to pick a shape before anything is priced in detail, warning that a wrong shape propagates into every line below it.",
"Identifies Kessler's motion as individual-developer adoption from the description of how developers arrive.",
"States that individual adoption sends money toward discoverability and time-to-first-success rather than toward field presence.",
"States that any line whose share nobody can explain is zero-based this cycle, whichever budgeting mode is chosen.",
"Names community-led as the shape the default efficiency order starves, together with the conditions that would promote it.",
"Applies a two-pillar concentration limit rather than spreading across every pillar, and justifies it on the consistency threshold below which devrel work does not pay.",
"Does not adopt last year's split as the starting point without it being explained.",
"Labels any archetype percentage weights it quotes as illustrative starting points for an argument rather than benchmarks."
]
},
{
"id": 12,
"prompt": "At Pallas Fabric we depend hard on one Rust crate that basically is our storage layer. One maintainer, and if they walk we're in trouble. I've got $40K for open source this year. My plan is $50 a month across our top 60 dependencies because that spreads goodwill widest per dollar, and then whatever's left over goes wherever. My CFO will love the coverage number. Sound right?",
"expected_output": "Breadth identified as the efficiency winner but the value loser, depth promoted for the critical-path crate with the promotion condition stated, hours priced for the line, the procurement invoice floor flagged, and the coverage count refused as an outcome unit.",
"files": [],
"expectations": [
"States that breadth beats depth on efficiency but loses to it on value, so a program ranked on ratio alone never funds depth.",
"Recommends promoting depth for the single Rust crate, because it carries the product's critical path.",
"States the second condition that promotes depth: a funded driver of supply-chain exposure rather than goodwill.",
"Contrasts the two motions' effort, with breadth a setup pass and near-zero after it, and depth days of diligence plus a standing relationship.",
"States what depth buys that breadth does not: a named maintainer who answers, rather than coverage and goodwill.",
"Prices hours for the sponsorship line, covering dependency selection, maintainer contact and diligence, invoicing and vendor onboarding, renewal reviews and internal reporting.",
"Warns that some funding platforms enforce an invoice minimum for procurement-routed payments, which sets a floor on any line routed through purchase orders.",
"Names the exit cost of a sponsorship: the return sits inside a surface someone else controls.",
"Does not rank the sponsorship line against another pillar by cost per unit.",
"Sets the depth portion up as an experiment with a kill date if no baseline exists for it.",
"Refuses the dependency coverage count as the line's outcome unit."
]
}
],
"trigger_queries": [
{ "query": "How should I split our devrel budget across events, content and community?", "should_trigger": true },
{ "query": "We have 180K for developer relations next year, help me plan where it goes.", "should_trigger": true },
{ "query": "what's a sensible devrel budget split", "should_trigger": true },
{ "query": "I need to defend my devrel spend at the annual review next month", "should_trigger": true },
{ "query": "Finance wants 20% out of my developer relations budget by Friday. What do I cut first?", "should_trigger": true },
{ "query": "We spend way too much on conferences and I can't prove it either way.", "should_trigger": true },
{ "query": "Nobody will tell me what our devrel budget actually is and I still have to plan the year.", "should_trigger": true },
{ "query": "Is 40% on events too much for a devrel program?", "should_trigger": true },
{ "query": "How much of our developer relations money should go to docs and tooling?", "should_trigger": true },
{ "query": "Build me a line-item plan for developer advocacy spend this fiscal year", "should_trigger": true },
{ "query": "our devrel budget got cut by a third, what survives", "should_trigger": true },
{ "query": "I want to zero-base our developer relations spend this cycle instead of copying last year", "should_trigger": true },
{ "query": "Should I renew the conference contract or put that money into content?", "should_trigger": true },
{ "query": "What return should each devrel line have to hit to keep its funding?", "should_trigger": true },
{ "query": "help me write the cut list for my developer relations program", "should_trigger": true },
{ "query": "We keep funding five things at 20% each and nothing lands. What should we do differently?", "should_trigger": true },
{ "query": "How do I price the hours behind our devrel plan, not just the cash?", "should_trigger": true },
{ "query": "My devrel plan balances on paper but the team is drowning. Did I under-budget something?", "should_trigger": true },
{ "query": "how much should we hold back unallocated for opportunities that come up mid-year", "should_trigger": true },
{ "query": "what percentage of our developer relations money should be reserve", "should_trigger": true },
{ "query": "The VP wants a one-pager explaining where the developer relations money goes.", "should_trigger": true },
{ "query": "We got a 15% increase in devrel funding. Where should the extra go?", "should_trigger": true },
{ "query": "I need to decide between hiring an agency for content or sponsoring three more conferences.", "should_trigger": true },
{ "query": "Our developer relations program budget for FY28, help me build it from scratch.", "should_trigger": true },
{ "query": "which developer relations line should die first if we lose funding", "should_trigger": true },
{ "query": "Should devrel money go to a certification program or to better docs?", "should_trigger": true },
{ "query": "how do I decide between community investment and paid distribution with a fixed pot", "should_trigger": true },
{ "query": "We're planning next year's developer marketing spend and I don't know where to start.", "should_trigger": true },
{ "query": "Our board asked how we decided the developer relations split. I don't have a good answer.", "should_trigger": true },
{ "query": "Is it worth sponsoring open source projects out of the devrel budget, and how much?", "should_trigger": true },
{ "query": "Help me figure out what our developer advocacy program can actually afford this year.", "should_trigger": true },
{ "query": "Every team says devrel should fund their thing. How do I say no with a rule instead of a vibe?", "should_trigger": true },
{ "query": "I want a review cadence for each devrel line so renewals aren't political.", "should_trigger": true },
{ "query": "we have money to spend before the fiscal year closes and nothing planned", "should_trigger": true },
{ "query": "what should I stop funding in developer relations", "should_trigger": true },
{ "query": "Give me two or three whole-budget options for our developer relations program, not one.", "should_trigger": true },
{ "query": "My devrel plan has no hours in it and I think that's a problem.", "should_trigger": true },
{ "query": "how to justify the devrel number to a CFO who thinks it's marketing fluff", "should_trigger": true },
{ "query": "Our developer relations spend went up 40% and results didn't move. Where do I look?", "should_trigger": true },
{ "query": "Split $500K across developer experience investments for a platform company.", "should_trigger": true },
{ "query": "I inherited last year's devrel percentages and nobody can explain them.", "should_trigger": true },
{ "query": "Should we keep paying for the Discord or put that money into the quickstart instead?", "should_trigger": true },
{ "query": "We can't travel this year. What happens to the money we used to spend on conferences?", "should_trigger": true },
{ "query": "Our one advocate is maxed out but I still have cash left. What can I actually fund?", "should_trigger": true },
{ "query": "how much does a devrel program cost to run properly", "should_trigger": true },
{ "query": "I need a reallocation rule so mid-year changes aren't a fight every time.", "should_trigger": true },
{ "query": "Plan the spending for our developer ecosystem program next year.", "should_trigger": true },
{ "query": "What's the right mix of compounding work versus quick wins in a devrel plan?", "should_trigger": true },
{ "query": "help me build the cut scenarios for a 20% and a 40% reduction in developer relations", "should_trigger": true },
{ "query": "Our DevRel team wants a bigger budget. How do I evaluate whether that's justified?", "should_trigger": true },
{ "query": "Is our developer relations spend on the right things?", "should_trigger": true },
{ "query": "I've got a launch in ten weeks and unspent developer relations budget. What can I fund that lands in time?", "should_trigger": true },
{ "query": "developer relations budget planning template", "should_trigger": true },
{ "query": "how do other companies split devrel spend and should I copy them", "should_trigger": true },
{ "query": "My VP asked for the devrel budget ask six weeks before the cycle locks. What goes in it?", "should_trigger": true },
{ "query": "We want to fund an OSS sponsorship line. How big, and across how many projects?", "should_trigger": true },
{ "query": "Should the community platform licence come out of my program budget or out of headcount?", "should_trigger": true },
{ "query": "I want each developer relations line to have a kill rule written before we spend.", "should_trigger": true },
{ "query": "how to allocate developer marketing money when adoption is self-serve", "should_trigger": true },
{ "query": "Enterprise deals need us at events but our budget favours content. How do I resolve that?", "should_trigger": true },
{ "query": "We have three funded pillars and I suspect that's one too many.", "should_trigger": true },
{ "query": "what goes wrong when a devrel plan only counts money", "should_trigger": true },
{ "query": "I need to show the trade-off we're making, not just the final numbers.", "should_trigger": true },
{ "query": "Our developer relations budget excludes salaries. Does that change how I compare us to others?", "should_trigger": true },
{ "query": "Help me decide what to fund for developer adoption with 95,000 pounds.", "should_trigger": true },
{ "query": "rank our developer relations investments by what they actually return", "should_trigger": true },
{ "query": "I want to stop renewing devrel lines by default.", "should_trigger": true },
{ "query": "What should I do with the 12K left over in the developer relations line?", "should_trigger": true },
{ "query": "How do I plan developer relations spending when I don't know next year's number yet?", "should_trigger": true },
{ "query": "Which devrel metrics should I report to the exec team?", "should_trigger": false },
{ "query": "How do I prove devrel ROI to my CEO?", "should_trigger": false },
{ "query": "Build me a devrel scorecard for quarterly reporting.", "should_trigger": false },
{ "query": "What's a good attribution rule for developers who found us through the docs?", "should_trigger": false },
{ "query": "Our numbers look good but leadership still isn't convinced. What am I measuring wrong?", "should_trigger": false },
{ "query": "How much pipeline should the devrel program be expected to influence?", "should_trigger": false },
{ "query": "Should we even be doing developer relations at this stage?", "should_trigger": false },
{ "query": "What should a brand-new devrel program do in its first 90 days?", "should_trigger": false },
{ "query": "Which pillars should our devrel program run at all?", "should_trigger": false },
{ "query": "Our devrel work is busy but nothing lands. What's the strategic problem?", "should_trigger": false },
{ "query": "Write the refused list for our developer relations program.", "should_trigger": false },
{ "query": "Was the KubeCon booth worth it?", "should_trigger": false },
{ "query": "Which conferences should we sponsor next year and at what tier?", "should_trigger": false },
{ "query": "How do I negotiate a better sponsorship package with an event organiser?", "should_trigger": false },
{ "query": "Design the on-site booth activation for our next conference.", "should_trigger": false },
{ "query": "What should we do in the 48 hours after a conference to follow up on leads?", "should_trigger": false },
{ "query": "Who should devrel report to, marketing, product or engineering?", "should_trigger": false },
{ "query": "Should our devrel team be centralized or embedded in product squads?", "should_trigger": false },
{ "query": "When do we need to re-org the developer relations team?", "should_trigger": false },
{ "query": "Our developer relations team wants headcount for a second advocate. How do I evaluate the ask?", "should_trigger": false },
{ "query": "Write a job description for a senior developer advocate.", "should_trigger": false },
{ "query": "What should I look for when interviewing a developer advocate?", "should_trigger": false },
{ "query": "What should we pay a developer advocate based in Berlin?", "should_trigger": false },
{ "query": "How do I break into developer relations from a backend engineering role?", "should_trigger": false },
{ "query": "Is the IC track or the management track better for a DevRel lead?", "should_trigger": false },
{ "query": "Review my developer advocate resume.", "should_trigger": false },
{ "query": "Set up an event taxonomy for our docs analytics.", "should_trigger": false },
{ "query": "Our GitHub numbers don't match Google Analytics. How do I reconcile them?", "should_trigger": false },
{ "query": "What UTM conventions should we use across our devrel links?", "should_trigger": false },
{ "query": "Help me build an identity spine that joins docs visits to signups.", "should_trigger": false },
{ "query": "What should we charge for our API product?", "should_trigger": false },
{ "query": "Where should the free tier end and paid begin for our CLI tool?", "should_trigger": false },
{ "query": "Should we bill per seat or per usage?", "should_trigger": false },
{ "query": "How do we raise prices without a developer backlash?", "should_trigger": false },
{ "query": "Model the unit economics of our free tier.", "should_trigger": false },
{ "query": "Open core or open source with a hosted product, which business model?", "should_trigger": false },
{ "query": "Should our project be Apache 2.0 or AGPL?", "should_trigger": false },
{ "query": "Set up GitHub Sponsors tiers for my open source project.", "should_trigger": false },
{ "query": "How do I get companies to sponsor my open source library?", "should_trigger": false },
{ "query": "What rewards should I offer corporate sponsors of my OSS project?", "should_trigger": false },
{ "query": "How should sponsor logos appear in our README without looking like an ad?", "should_trigger": false },
{ "query": "Plan the editorial calendar for our developer blog next quarter.", "should_trigger": false },
{ "query": "How often should we publish technical content?", "should_trigger": false },
{ "query": "We're starting a Discord for our users. How do we launch it?", "should_trigger": false },
{ "query": "Write the moderation rules for our developer community.", "should_trigger": false },
{ "query": "Our community is quiet. How do I measure whether it's healthy?", "should_trigger": false },
{ "query": "How do I run a recurring meetup and find speakers every month?", "should_trigger": false },
{ "query": "Design a champions program for our most active users.", "should_trigger": false },
{ "query": "Should we open our API to third-party integrations?", "should_trigger": false },
{ "query": "Nobody builds on our platform. Why?", "should_trigger": false },
{ "query": "Design the curriculum for a certification program for our partner integrators.", "should_trigger": false },
{ "query": "How do we compare against our competitor's developer experience?", "should_trigger": false },
{ "query": "Write a CFP abstract for a platform engineering conference.", "should_trigger": false },
{ "query": "How do we launch our open source project on Hacker News?", "should_trigger": false },
{ "query": "Rewrite our quickstart so developers get to a first API call faster.", "should_trigger": false },
{ "query": "Audit the structure of our documentation site.", "should_trigger": false },
{ "query": "Which keywords should our developer docs target?", "should_trigger": false },
{ "query": "Turn these commits into release notes.", "should_trigger": false },
{ "query": "Write a case study about a customer who migrated to our SDK.", "should_trigger": false },
{ "query": "Which developer segments should we prioritize this year?", "should_trigger": false },
{ "query": "How should I allocate our paid ads budget across Google, LinkedIn and Reddit?", "should_trigger": false },
{ "query": "Split our marketing budget across brand and performance for next year.", "should_trigger": false },
{ "query": "What's a reasonable R&D budget as a percentage of revenue?", "should_trigger": false },
{ "query": "Allocate engineering capacity across features, bugs and tech debt next quarter.", "should_trigger": false },
{ "query": "Plan the budget for the developer conference we're organising ourselves.", "should_trigger": false },
{ "query": "How much should we charge for sponsor booths at our own event?", "should_trigger": false },
{ "query": "Write the sponsorship prospectus for the conference we host.", "should_trigger": false },
{ "query": "Create a partner program tier structure with revenue share.", "should_trigger": false },
{ "query": "Which podcasts, newsletters and people should I follow to keep up with developer relations?", "should_trigger": false }
]
}
references/allocation-archetypes.md›
# Allocation archetypes
Whole-budget shapes to build brainstorming candidates from in step 3. Each is a bet, not a best practice. The weights are illustrative starting points for an argument, so present them as proposals and adjust them against the program's own evidence.
## Contents
- How to use these
- Enablement-first
- Content-compounding
- Field-and-events
- Community-led
- Ecosystem and sponsorship
- Barbell
- Matching an archetype to stage, driver and motion
- Anti-patterns
## How to use these
Shortlist two or three shapes from the default ordering in step 3 of the skill, which ranks them on effort, value and efficiency; this page is the per-shape detail behind that order, and its section order carries no ranking of its own. Price each shortlisted shape as a whole budget and show what it starves. The choice between them is the real decision; the line-level numbers are consequences.
Weights below refer to discretionary spend after the reserve, and they are cash-and-hours weights together - a pillar can be 10% of cash and 40% of hours, which is exactly the distortion this exercise exists to expose.
Effort in magnitudes, which is what the ordering ranks on:
| Shape | Hours shape | Time to a readable signal | Exit cost |
| ------------------------- | ----------------------------------------------------- | --------------------------- | --------------------------------- |
| Enablement-first | a quarter to build, then a standing maintenance shift | weeks | low, but decay is actively wrong |
| Content-compounding | a quarter of setup, then a standing review shift | two to three quarters | near-zero; published work stays |
| Field-and-events | bursts of a week per edition, plus follow-up | one edition | contract notice period |
| Community-led | a standing job that cannot be paused | a year or more | unrecoverable: wound-down trust |
| Ecosystem and sponsorship | near-zero for breadth, days for depth | a year, and weakly readable | contract term, plus a public exit |
## Enablement-first
Weights: docs, tooling and samples 45-55% · content 20% · community 15% · events 10%.
Funds the path from first contact to first success: quickstarts, samples that run, SDK maintenance, a sandbox, troubleshooting content.
Starves: reach. Nobody new discovers the product this period.
Right when: usage exists but conversion to real adoption leaks, support answers the same questions repeatedly, or the product just changed shape.
Wrong when: nobody is arriving at all. Polishing the funnel below an empty top produces nothing.
## Content-compounding
Weights: content 45-55% · docs and enablement 20% · events 15% · paid distribution 10%.
Funds a sustained publishing engine and the search-and-citation surface it builds.
Starves: anything with a date. This shape cannot deliver a launch beat, and it takes two to three quarters before results are readable.
Right when: the audience searches for the problem, review capacity exists, and leadership can wait a year for compounding.
Wrong when: the reviewer bottleneck is unresolved - the budget converts into drafts that never publish.
## Field-and-events
Weights: events 50-60% · content 20% · enablement 15%.
Funds physical presence where buyers and approvers stand: conferences, workshops, dinners, regional meetups.
Starves: the self-serve path and the compounding surfaces. Spend stops working the moment the team stops travelling.
Right when: the motion is enterprise, the deal needs a human, and the ecosystem has a small number of events where the whole buying group appears.
Wrong when: adoption is individual and self-serve. Historically this is where DevRel money defaults - the surveyed mean puts events at the top of the split - so treat a heavy event line as a choice to defend, not a default to inherit.
## Community-led
Weights: community 40-50% · content 25% · events 15% · enablement 15%.
Funds a venue, the people who staff it, champions and recognition, and community-run events.
Starves: everything with a short horizon. Community pays back slowly and unevenly, and it cannot be paused - a dormant venue is worse than none.
Right when: peer-to-peer questions already happen somewhere, the product has enough users to reach critical mass, and a named person owns the venue permanently.
Wrong when: the user base is too small or too enterprise to sustain public peer conversation, or the staffing is a volunteer's spare time.
## Ecosystem and sponsorship
Weights: OSS sponsorship and partner programs 35-45% · content 20% · events 20% · enablement 15%.
Funds presence inside other people's ecosystems: sponsored projects, partner enablement, integration bounties, foundation membership.
Starves: the owned surfaces. The program's credibility becomes partly borrowed and partly out of its control.
Right when: the product's value depends on ecosystems it does not own, or supply-chain and dependency exposure is already a funded corporate concern.
Wrong when: the company's own docs and onboarding are weak - traffic arrives and bounces.
## Barbell
Weights: two heavy poles (typically enablement plus one reach pillar) at ~40% each · everything else at token level · experiments 10-15% with kill dates.
Not ranked alongside the other five, and deliberately so: it is a concentration rule applied on top of whichever shape wins, not a pillar mix of its own, so scoring it against them would be false precision. Deliberately refuses the middle. Funds the foundation that raises every other channel's yield, plus one concentrated bet, and treats the rest as explicitly unfunded.
Starves: optionality. If the single reach bet fails, the period produces only foundation work.
Right when: the envelope is small, the team is two to five people, and previous periods spread thin and cleared nothing.
Wrong when: the funder expects visible activity across every pillar, in which case the refusal has to be negotiated before the plan is written, not after.
## Matching an archetype to stage, driver and motion
| Situation | Usual fit | Why |
| ----------------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------ |
| Seed stage, one generalist | Barbell over enablement-first | One person cannot clear a threshold in more than two pillars |
| Growth stage, adoption driver, individual motion | Content-compounding or enablement-first | Discoverability and time-to-first-success are the constraint |
| Growth stage, sales-enablement driver, company motion | Field-and-events | Approvers are reachable in person; proof material travels with the field |
| Established, contributor-community driver | Community-led | The venue and the contributor ladder are the product surface |
| Product depends on other ecosystems | Ecosystem and sponsorship | Distribution is rented from ecosystems the company does not own |
| Budget just cut by a quarter or more | Barbell over whichever shape the driver names | Forced concentration beats an even trim that clears nothing |
## Anti-patterns
- **The inherited split.** Last year's percentages with this year's total. It encodes decisions nobody currently agrees with.
- **The peanut butter spread.** Every pillar at 20% so no stakeholder objects. No pillar reaches the consistency threshold where devrel work starts to pay.
- **The copied enterprise shape.** A large company's mix presupposes brand, leverage programs and headcount a small program does not have.
- **The unpriced pillar.** A pillar listed with a small cash figure and no hours, because "the team already does that". It is the largest line in the plan and it is invisible.
references/allocation-example.md›
# Worked allocation
A complete allocation for a fictional Series A API-observability company: 40 employees, self-serve entry with a sales-assisted enterprise tier, one advocate, one technical writer, one half-time community manager. Numbers are illustrative and internally consistent; copy the shape, never the figures.
## Contents
- The finished document
- Weak versus strong: envelope
- Weak versus strong: threshold
- Weak versus strong: review rule
- Weak versus strong: cut list
- Weak versus strong: funder narrative
- Negative example: the plan that balances on cash and fails on hours
## The finished document
### Envelope - FY, EUR
- **Total program budget: 240,000. Salaries excluded** - 2.5 devrel FTE sit on a separate headcount line owned by the VP Marketing.
- **Committed: 38,000** - community platform licence 6,000 (renews 1 Nov, 60-day notice); two-year conference contract 32,000 (final year).
- **Discretionary: 202,000** - the number allocated below.
- **Borrowed: ~25,000** - field marketing funds two regional customer dinners. Owner: Demand Gen. Not depended on by any line here.
- **In-kind** - 6 h/week of staff-engineer review time, agreed with the platform lead, capped.
- **Hours envelope: 3,680 h/year** (advocate 30 h/wk, writer 32, community manager 18, over 46 working weeks). **Planned against: 2,760 h** after the 25% deduction for support load, launches and incidents.
Primary motion this period: individual self-serve adoption, with enterprise evaluation second. Funded driver: developer adoption. Both stated by the VP Marketing, who signs.
### Allocation
| Line | Pillar | Cash | Hours | Owner | Buys | Threshold | Review | If it misses |
| ----------------------------- | ---------- | ----------- | --------- | ----------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------- | ------------------------ | ---------------------------------- |
| Docs, samples and sandbox | Enablement | 34,000 | 900 | Writer | Quickstart rewrite, 4-language sample parity in CI, hosted sandbox | p50 time-to-first-success < 12 min (baseline 22); samples green ≥ 95% of days | Quarterly | Drop sandbox, keep samples |
| Technical content pipeline | Content | 52,000 | 700 | Advocate | 24 slotted pieces, agency drafts, in-house outlines and review | ≥ 20 published and reviewed; median 450 sessions at 90 days (baseline 380) | Quarterly | Cut agency, 12 in-house pieces |
| Events | Events | 58,000 | 620 | Advocate | 1 flagship booth, 3 partner workshops | ≤ 700 per qualified conversation fully loaded; ≥ 120 conversations (baseline 84 at 810) | 2 weeks after each event | Renegotiate booth to workshop tier |
| Community venue and champions | Community | 18,000 | 420 | Community manager | Moderation cover, recognition, 8 champions | ≥ 60% of questions answered < 24 h; ≥ 25 monthly active askers by Q4 (baseline 9) | Quarterly | Cut champions, keep answering |
| OSS sponsorship | Ecosystem | 10,000 | 60 | Advocate | Breadth across dependency graph, depth on 3 load-bearing projects | Experiment - named maintainer relationships on all 3 by Q3 | Q3 | Keep breadth, drop depth |
| Experiments (2) | - | 6,000 | 60 | Advocate | 1 sponsored newsletter run, 1 video series pilot | Each ships by its kill date with a written read | Kill date per experiment | Close, do not extend |
| Reserve | - | 24,000 | - | VP Marketing | Unallocated | - | Quarterly | - |
| **Total** | | **202,000** | **2,760** | | | | | |
Horizon split of the 178,000 allocated: compounding 104,000 (58%), scaling the working bet 58,000 (33%), experiments 16,000 (9%). Deliberately heavier on compounding than the familiar 70/20/10 shape, because the enterprise motion is second this period and the events line is already proven.
### Unfunded list - ranked, lost on the ranking
- Certification program - revisit when self-serve activation exceeds 500/month; no evidence of demand yet.
- Second regional community - one venue is the rule until the first clears its answer-rate threshold.
### Ruled out - never ranked
- Conference speaking tour beyond the funded events - constraint: it breaches the advocate's hours ceiling. Back on the table only if a second advocate is hired.
### Review clocks
Burn monthly (cash rate and hours actually logged) · line verdicts quarterly, events two weeks after each edition · envelope at the annual cycle, draft ask due six weeks before it locks.
### Reallocation triggers
A line misses its threshold twice · the funded driver or the VP Marketing changes · the conference contract reaches its 60-day notice date · the writer or community manager leaves · an opportunity clears a higher bar than the experiments line, which is drawn from first.
### Cut list
| Cut | Removes | Consequence |
| ------------- | -------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| −20% (40,400) | 2 of 3 workshops (18,000); agency volume halved (16,000); OSS depth (6,000) | Enterprise evaluation coverage drops to one event; content output falls to ~14 pieces; ecosystem line becomes breadth-only |
| −40% (80,800) | The above plus the flagship booth (32,000), replaced by speaking-only attendance | No enterprise field presence; pipeline contribution becomes unmeasurable this year; compounding surfaces protected |
This is step 4's efficiency order read from the bottom: rented reach goes first (workshops, sponsorship depth, then the booth), and the foundational override holds the rest. Docs, samples and the community answer rate are cut last: they are the surfaces whose neglect is actively harmful rather than merely invisible.
### Narrative for the funder
We fund developer adoption. Most of the money goes to the two things that compound - the path from landing page to first working call, and the technical content people find when they search for the problem. One flagship event and three workshops keep the enterprise evaluation motion alive, priced at under 700 euros per qualified conversation. Twelve percent stays unallocated so we can act on what appears mid-year. If the budget is cut by a fifth, we drop workshops and agency volume first, and we protect the docs.
## Weak versus strong: envelope
**Weak** - "Our devrel budget is 240K." Comparable to nothing, hides 38,000 of committed spend and the entire hours constraint, and invites a benchmark comparison against programs that include salaries.
**Strong** - the envelope section above: salaries named as excluded, committed spend separated with its notice date, borrowed money attributed to its real owner, hours stated and discounted.
## Weak versus strong: threshold
**Weak** - "Events should generate strong pipeline." Unmeasurable, so the line renews on vibes.
**Strong** - "≤ 700 per qualified conversation fully loaded; ≥ 120 conversations; baseline 84 at 810 last year." Derived from the program's own prior period, with the qualification bar written before the event and briefed to every staffer.
## Weak versus strong: review rule
**Weak** - "We will review the budget quarterly." One clock for three different questions, so burn-rate detail crowds out the renew-or-drop decision.
**Strong** - three clocks at different rhythms, each with its own question, plus written triggers that fire between reviews.
## Weak versus strong: cut list
**Weak** - "We could absorb a 20% cut if we had to." Hands the ordering to whoever runs the spreadsheet, and an even trim starves the compounding lines first.
**Strong** - the ordered table above: what goes, in which order, with the consequence of each removal named in one sentence.
## Weak versus strong: funder narrative
**Weak** - "DevRel drives awareness and community engagement across multiple channels, supporting the funnel end to end." No decision is visible, so the budget reads as an activity list.
**Strong** - the five sentences above: one driver, the concentration choice, the one number the events line is held to, the reserve, and the cut order. A funder can repeat it in a meeting the devrel lead is not in.
## Negative example: the plan that balances on cash and fails on hours
Same fictional company, same 202,000 discretionary. This version is the one that gets approved in the room and collapses in month four. Read it as a diagnosis exercise: five defects, all of them common, none of them visible to a reviewer who only checks that the cash column adds up.
| Line | Pillar | Cash | Hours | Owner | Threshold | Review |
| ----------------------- | ---------- | ----------- | ----- | ----------- | ----------------------------- | ----------- |
| Conferences (4) | Events | 72,000 | - | DevRel | Build awareness and pipeline | End of year |
| Content | Content | 40,000 | - | DevRel | 40 blog posts | End of year |
| Community | Community | 20,000 | - | DevRel | Grow Discord to 2,000 members | End of year |
| Docs and samples | Enablement | 25,000 | - | Engineering | Keep docs current | - |
| Certification program | Education | 30,000 | - | DevRel | Launch by Q4 | - |
| Newsletter sponsorships | Paid | 15,000 | - | DevRel | Drive signups | - |
| **Total** | | **202,000** | | | | |
What is wrong with it:
1. **No hours column at all.** Priced out afterwards, the four conferences alone consume roughly 800 hours, the certification launch is over 600, and docs "owned by Engineering" is an unfunded claim on a team that never agreed to it. Total planned work exceeds the 2,760-hour envelope by more than half. The cash is real; the plan is not.
2. **Six pillars, none concentrated.** No line is large enough to clear a consistency threshold, so the year produces activity in every column and a result in none.
3. **Thresholds that cannot fail.** "Build awareness", "keep docs current" and "drive signups" have no unit and no number, so every line renews by default. "2,000 Discord members" has a number but counts joins, which a giveaway can buy without producing a single answered question.
4. **One owner for five lines, one review date for all of them.** "DevRel" is a team, not a person, and an end-of-year review arrives after every decision it was supposed to inform.
5. **No reserve, no unfunded list, no cut list.** The first mid-year opportunity has to be taken out of a funded line, and a 20% cut arrives as a flat trim that hits the compounding surfaces hardest.
The repair is not a bigger budget:
- Price the hours.
- Drop to two funded pillars plus maintenance.
- Name a person per line.
- Give each a unit and a baseline-derived number.
- Hold back a reserve.
- Write the cut order before anyone asks for it.
references/budget-benchmarks.md›
# Published DevRel budget figures
Everything below comes from one source: the _State of Developer Relations 2024_ report (11th annual survey), run by DevRel.Agency and published at `stateofdeveloperrelations.com/2024devrelreport` on 10 September 2024 - 310 valid respondents, 242 completions, 33 countries. These figures are two budget cycles old, so check for a newer edition before quoting them.
Treat this page as evidence for framing an argument, never as a target to hit. Say the sample size out loud whenever you quote a number from it.
## Annual program budget
| Band | Share | Movement vs 2023 |
| ------------- | ----- | -------------------------------------------------- |
| Under $100K | 16.7% | down from 36.7% |
| $10K-$50K | 4.6% | down from 15.1% |
| $101K-$500K | 12.8% | up from 8.4% - most frequently reported known band |
| Over $1M | 6.8% | - |
| No set budget | 17.8% | - |
| Not sure | 33.5% | - |
The most useful row is the last one. A third of practitioners cannot state their own budget and another sixth have none, so a user who does not know their number is in the majority, not in trouble. Establishing the envelope is a legitimate first deliverable.
## Salary inclusion
- 60% of program budgets exclude staff salaries.
- 26% include salaries for all DevRel roles; 3% for some roles.
Consequence: the program budget and the headcount budget usually have different owners and different approval cycles. No two budgets - and no budget against these bands - can be compared until both state whether salaries are inside.
## Direction of travel over the trailing 12 months
Increased 29% (up from 16% in 2023) · No change 24% · Decreased 24% (down from 37%).
Read: the 2023 contraction eased, but roughly a quarter of programs still lost budget in a single year. Planning for a cut is the base case, not pessimism - which is why the allocation ships with an ordered cut list.
## The allocation split, and its three caveats
Question asked: "Of your total budget, what % is allocated to each of the following categories?"
| Category | Mean share |
| --------------------------- | ---------- |
| Events | 41.1% |
| Staff salaries | 30.9% |
| Content production/creation | 19.5% |
| Marketing/promotion/ads | 13.0% |
1. **n = 47.** The question was shown only to respondents who said they knew their budget. This is a small-sample average, not an industry standard.
2. **The shares sum to 104.5%**, so respondents answered on inconsistent bases - some including salaries, some not.
3. **The category set is incomplete.** Community, developer tooling and infrastructure, OSS sponsorship, and education or certification have no row at all, so their spend is hidden inside the four buckets. A pillar-based allocation cannot be mapped onto this table one-to-one.
Honest uses:
- To show that events have historically dominated devrel spend, so a plan that funds them lightly is making a deliberate, defensible departure.
- To ask a team whose split looks nothing like this what they know that the field does not - a question that usually produces a good answer or exposes an inherited split.
Dishonest uses, which will be caught:
- Presenting 41.1% as the correct event share.
- Benchmarking a specific program against these means.
- Implying the four categories are the standard taxonomy.
## Related structural findings from the same survey
- Reporting line: marketing 33.1%, product 21.7%, CEO 20.3%, engineering 19.9%, sales 3.2%. No line holds a majority, and the line usually determines who signs the budget.
- 43.6% report more than one team performing devrel activities, up from 33% - so a single program budget frequently understates total company spend on the function.
- Team size: 2-5 people is the most common band at 35.2%; solo practitioners 18.2%; 69% of teams are under 10 people.
The fragmentation figure matters for allocation: before claiming a pillar is underfunded, check whether another team is already funding it from a budget nobody in the conversation controls.
## Borrowed heuristics from adjacent disciplines
Each comes from outside DevRel, each is in circulation, each is useful as a starting point, and each has to be introduced as borrowed.
| Heuristic | Where it comes from | What it is good for |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| 10-15% contingency plus a testing reserve, and concentrating the majority of spend on the highest-confidence channel | published marketing campaign-planning guidance | corroborating the 10-20% reserve from outside DevRel - two disciplines landing in the same band is weak evidence, not a standard |
| Kill rules stated as "repeatable and cheap to apply, not statistically rigorous" | paid-media practice | the honest framing for any pre-set threshold; it defuses the attribution argument before it starts |
| Fund where outcome share exceeds budget share | paid-media demand-stage planning | a cross-pillar comparison that survives incompatible units, because it compares two ratios rather than two costs |
| Fully-loaded cost = 1.3-1.4× base salary | startup headcount planning; widely repeated, no traceable original source | a last-resort way to price hours when the organisation publishes no loaded rate - state the multiplier and its weak basis in the document |
| Fully-loaded cost, Europe = 1.15-1.5× base salary, narrower once split by country and sector: UK tech/SaaS ≈1.25-1.35×, UK financial services and public sector ≈1.3-1.4×, France ≈1.3-1.5×, Netherlands professional roles above 1.3× | two dated 2026 employer-of-record cost guides (Teamed; Grove Financial) covering UK and continental Europe | the regional adjustment when the program is not US-based; still a general HR cost guide, not a DevRel-specific figure |
| Zero-based budgeting: every line restarts at zero and is ranked into a funded list | Peter A. Pyhrr, Texas Instruments, early 1970s; his own account in _Public Administration Review_ 37(1), 1977, "The Zero-Base Approach to Government Budgeting" (title confirmed via search) | the named method for refusing an inherited split, and its ranked list doubles as the cut list |
| Payback measured per plan or cohort rather than as one blended ratio | subscription-marketing practice | the argument, not the formula: a single blended ratio hides the variance the decision actually turns on |
## Numbers to refuse rather than estimate
Say plainly that these are not figures anyone can quote, rather than inventing one:
- DevRel budget as a percentage of revenue, of marketing spend, or per developer reached.
- Cost per developer acquired, per community member, or per documentation page.
- A recommended split across community, tooling, education or sponsorship.
- Headcount-to-budget ratios at any stage.
For each of them, the program's own prior period is the only legitimate baseline, and where even that is missing, the line is an experiment with a kill date rather than a funded bet.
references/line-item-cost-model.md›
# Line item cost model
What each pillar's line really costs, in cash and in hours. Use this while pricing candidate lines in step 2. The hours column is the one that decides whether a line is fundable; the cash column is the one that gets approved.
## Contents
- The two-number rule
- Events
- Content
- Community
- Documentation, tooling and enablement
- Education and certification
- OSS sponsorship and funding
- Paid distribution
- Documented setup costs and latencies
- Fully loaded hour rate
## The two-number rule
Every line carries a cash figure and an hours figure. Derive hours from named people, never from a team average - "engineering will review it" is not a funded reviewer.
Count hours across the whole life of the line: preparation, delivery, and the follow-up load that arrives afterwards. Follow-up is the systematically missing column. A conference produces a week of replies, a popular post produces a support queue, a community launch produces a permanent moderation shift.
## Events
Cash: sponsorship fee, paid add-ons, booth build and shipping, swag, printing, prizes and credits, travel, accommodation, per diem for every attendee, event-specific landing page or promo infrastructure.
Hours: pitch and package negotiation, booth design, pre-event promotion, travel days, on-site days for every staffer, 48-hour follow-up, and the post-event review. Staff time at loaded cost is the line most teams omit and the one that most often doubles the true total.
Opportunity cost: what those engineer-days would otherwise have shipped. Record it as a note even if it never enters the table.
## Content
Cash: agency or freelance fees, editing, illustration and diagrams, video production and editing, stock and licensing, hosting and CDN, syndication or placement fees.
Hours per piece - count in passes, not in drafts: research, drafting, writing code that actually runs, technical review by someone who can dispute the claims, edits, assets, publishing, then promotion and replies. Estimate per format; a changelog entry, a checkpointed tutorial and a benchmark post differ by an order of magnitude.
The scarce resource is the reviewer, not the writer. A plan that assumes unlimited review capacity stalls in the review column, where nothing has visibly slipped yet.
## Community
Cash: platform licence or tier, moderation and analytics tooling, swag and recognition, community-event or meetup costs, contractor moderation cover.
Hours: daily presence and answering, moderation and incident handling, program management for champions or ambassadors, onboarding new members, reporting. Community is the pillar with the highest ratio of recurring hours to cash - a platform that costs little per month can consume a half-time person indefinitely.
Exit cost is unusually high: a community that is wound down or migrated damages trust in a way a cancelled sponsorship does not.
## Documentation, tooling and enablement
Cash: docs platform or hosting, search, versioning and preview infrastructure, sandbox or playground compute, SDK release automation, code-sample CI minutes, technical writing contractors.
Hours: writing, engineering review, sample maintenance across languages, keeping every sample running in CI, and the per-release update tax. This pillar's cost is dominated by maintenance, not creation, and the maintenance is unavoidable - stale docs and broken samples actively cost trust rather than fading quietly.
## Education and certification
Cash: authoring tools, lab or sandbox platform, video production, exam platform, proctoring, item development, translation.
Hours: curriculum design, content authoring, subject-matter review, item writing and review, per-release realignment when the product changes, learner support. Certification adds permanent obligations: item security, cheating response and recertification cycles, all of which recur every year the credential exists.
## OSS sponsorship and funding
Cash: monthly or annual sponsorships, one-off grants, foundation memberships, bounties. Note that some platforms enforce an invoice minimum for procurement-routed payments, which sets a floor on any line that must go through purchase orders.
Hours: dependency-graph selection, maintainer contact and diligence, invoicing and vendor onboarding, renewal reviews, and internal reporting on what the money bought.
Two motions cost very differently: breadth (small amounts across many dependencies, largely automatable) and depth (larger judgement-based amounts to a few load-bearing projects, entirely manual).
- effort, heaviest first: `depth > breadth` - depth is days of diligence and a standing relationship; breadth is a setup pass and near-zero after it.
- value: `depth > breadth` - depth buys a named maintainer who answers; breadth buys coverage and goodwill.
- efficiency: `breadth > depth` - so a program ranked on ratio alone never funds depth. Promote depth when a single project carries the product's critical path, or when the driver is supply-chain exposure rather than goodwill.
## Paid distribution
Cash: sponsored newsletters, podcast reads, developer-network placements, search or social ads, retargeting.
Hours: creative production, list vetting, tracking setup, reading results. The distinguishing property is decay: paid distribution stops working the day it stops being paid, so it belongs in the campaign horizon, never in the compounding one.
## Documented setup costs and latencies
From a published account of scaling developer content production with an agency (Matt Jarvis, Snyk, developerrelations.com case study):
- ~6 months of the DevRel director's own time to build the pipeline before it produced at volume.
- 8-9 weeks from conception to publication once a third party wrote the piece.
- Modelled per-piece impact used in that program: ~1,000 sessions for deeper technical pieces, ~500 for introductory ones.
Read: outsourcing raises throughput but adds a fixed setup cost and a two-month latency. Fund it where the goal is volume and compounding, never where the goal is a dated launch beat.
## Fully loaded hour rate
If the organisation publishes a loaded cost per hour, use it. If not:
1. Take salary plus employer costs and overhead.
2. Divide by realistic working hours.
3. State the assumption in the document.
The number matters less than applying the same one to every line - the purpose is comparability between options, not accounting accuracy.
Last resort, when no salary figure is available either: the multiplier circulating in startup headcount planning is **1.3-1.4× base salary** fully loaded, built from payroll taxes plus a per-head allowance for benefits and for workspace, equipment and software. It is a rule of thumb and it is US-shaped; employer social charges in much of Europe push the real multiplier higher. Use it only with the sentence "this multiplier is a rule of thumb, not a benchmark" attached, and replace it with the finance team's own figure the moment one exists.
Where a program's budget excludes salaries - the majority case - keep the hours column anyway and total it separately. The salary budget belongs to a different owner, but the capacity constraint is the same either way.
SKILL.md›
---
name: devrel-budget-allocation
description: Splits a developer relations budget across pillars - events, content, community, tooling, education, OSS sponsorship - into line items that each carry a cash cost, an hours cost, a pre-set return threshold, a review date and a reallocation rule, plus a ranked cut list. Use whenever someone asks how to plan or split a devrel budget, how much to spend on events versus content versus community, whether a line item is worth its money, how to defend a devrel budget at review, or what to cut first when the budget shrinks - even if they only say "we spend too much on conferences". Not the metrics framework (samber/developer-relations-skills@devrel-metrics) or one event's ROI (samber/developer-relations-skills@developer-event-sponsorship).
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# DevRel Budget Allocation
You are a developer relations budget planner. You turn a program's strategy into money and hours: which lines get funded, how much each one buys, what each must return to keep its slot, when each is reviewed, and which one dies first if the envelope shrinks.
The deliverable is a **budget allocation**: a table of line items plus the rules that govern them. You allocate money against a strategy that already exists - if there is no funded driver and no goal, stop and route the user to `samber/developer-relations-skills@devrel-strategy` first, because a budget split without one is just last year's split with new numbers.
Two facts shape every recommendation:
- DevRel's dominant input is staff time, not cash, so any plan priced only in currency under-books the resource that actually runs out.
- DevRel pillars are not measurable on a common scale, so a budget ranked by a single ROI number always overfunds whatever happens to be easiest to count.
## How to label every number
Tag every figure you state with one of three labels - say the tag in the same sentence as the number, and never let the second or third pass as the first.
| Label | What it means | Say it like this |
| ---------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sourced | Published, with a name, a date and a sample size | "The 2024 DevRel.Agency survey puts events at a mean 41.1% of program budget - n=47, and the shares sum to 104.5%, so it shows where the field's money has gone, not where yours should go." |
| Program baseline | This program's own prior period | "Last year you ran 84 qualified conversations at 810 each; this threshold is that baseline, plus the improvement the new spend is buying." |
| Self-set | This skill's starting point | "I am proposing a 15% reserve as a starting point - move it, and write down why, since no industry figure sets it for you." |
That one survey, two cycles old and with the caveats above, shows where the field's money went, not where a program's should go. Derive these numbers only from this program's own data, and say plainly that they are not industry figures instead of producing a plausible one:
- Devrel spend as a share of revenue or of marketing.
- Cost per developer reached.
- Headcount-to-budget ratio.
- Any split across community, tooling, education or sponsorship.
Several numbers in this skill are self-set starting points, not industry figures - adjust them freely:
- The 20-30% capacity deduction.
- The 10-20% reserve.
- The two-pillar concentration limit.
- Step 4's four-point readability score and its half-marks cut-off.
- The five-sentence narrative.
- Every percentage in the archetypes.
Details and honest phrasings are in [./references/budget-benchmarks.md](./references/budget-benchmarks.md).
## Route elsewhere first
- Which pillars the program should run at all, and why → `samber/developer-relations-skills@devrel-strategy`.
- Which numbers prove the program works → `samber/developer-relations-skills@devrel-metrics`.
- Splitting the event line across specific events and tiers → `samber/developer-relations-skills@developer-event-sponsorship`.
- Headcount, reporting line and who owns which budget → `samber/developer-relations-skills@devrel-team-structure`.
## Interview
Ask one question at a time, multiple-choice where you can. Stop as soon as you know the envelope, the driver and the real capacity; confirm the rest as the table takes shape.
**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. What number are we allocating, for what period, and in what currency?
2. Does that number include DevRel staff salaries, some of them, or none? (Roughly 60% of surveyed programs exclude salaries entirely - the answer changes every comparison downstream.)
3. Who signs it off, and when does the cycle lock?
4. What is already committed - signed contracts, annual licences, retainers - and for how long?
5. What DevRel work is paid from someone else's budget today (field marketing, engineering, product), and how stable is that?
6. Why does the company fund this work - adoption, sales enablement, developer enablement, product input, ecosystem, contributor community, employer brand? Which does the funder name first?
7. Do developers adopt individually with a card, or does a company decide? If both, which one is this period's priority?
8. By what date must a result be visible, and to whom?
9. Does this period owe a win inside it, or an asset that compounds past it? If both, which one is this period's job?
10. Who are the named people, and how many hours a week does each really have for devrel work after their other duties?
11. What is your ceiling beyond hours - headcount you can add, political capital for a public refusal, and how far past this period you may commit?
12. What did last period's money buy, and what result can you actually point at?
13. What is off-limits - no travel, no paid media, no agencies, a channel the founder refuses?
14. Did the budget go up, down or flat last cycle, and is a cut plausible this one?
Answers 8, 9, 11 and 13 re-rank the orderings in steps 3 and 4 before either is presented:
- **Q8, a date inside the period** - promotes rented reach and the renewal of a line that already clears its threshold, and deletes any line whose latency runs past the date: an outsourced content pipeline at roughly two months to first publication, a certification build at a quarter or more.
- **Q9, a compounding mandate** - does the reverse: promotes the compounding line above rented reach and holds it funded across two periods.
- **Q11, an effort ceiling below what the top-ranked line needs** - deletes that line rather than demoting it.
- **Q13, "No travel"** - deletes the field-and-events shape outright.
Say which answer moved which line when presenting the result.
If the user cannot answer question 1, that is the normal case rather than a failure: a third of surveyed practitioners cannot state their program's budget and another sixth have no set budget at all. Switch the deliverable to a short list of questions they must get answered - from whom, by when - and a provisional allocation expressed in percentages that survives whatever number comes back.
If your environment offers persistent memory, store the envelope, the split, each line's threshold and each review verdict. Budgets are annual and argumentative; the next session re-uses the verdicts instead of re-litigating them.
## Step 1 - Establish the real envelope
Sort every euro or dollar into four buckets before allocating anything:
- **Committed** - already signed. Not allocatable this cycle; only renewable or cancellable, and each has a notice date.
- **Discretionary** - the number actually being planned. This is what the rest of the workflow splits.
- **Borrowed** - devrel work paid from another team's line. Real capacity, foreign control, can disappear without notice. List it, mark the owner, never depend on it for a critical line.
- **In-kind** - engineer hours, exec time, product credits, donated infrastructure. No invoice, hard ceiling.
Then state the hours envelope alongside the cash: per named person, hours per week available for devrel work after support, meetings, and their other job. Total it for the period and subtract 20-30% before planning against it - support load, launches and incidents always arrive.
Write both totals at the top of the deliverable. A plan that never states its hours envelope will overspend it, and nobody will notice until the quarter fails while the cash is intact.
## Step 2 - Price each candidate line in cash and hours
Every line carries two numbers and five properties. Use [./references/line-item-cost-model.md](./references/line-item-cost-model.md) for the per-pillar checklist of what to count - it names the costs teams routinely forget.
The five properties to record for each line:
- **Setup cost before first output** - the one documented case, Snyk's agency content pipeline (Matt Jarvis, developerrelations.com case study, undated), took roughly six months of a director's time before producing at volume.
- **Latency** - that same pipeline ran 8-9 weeks from concept to publication, which disqualifies it for a dated launch beat.
- **Recurring maintenance** - the hours per month to keep the surface accurate forever, not just to build it.
- **Decay behaviour** - what neglect looks like: invisible (acceptable) or actively wrong, like a stale listing or a broken sandbox (only fund it if the maintenance hours are funded too).
- **Exit cost** - what happens to the surface when the contract, the sponsorship or the person ends.
Flag immediately any line whose hours exceed the hours envelope. It is unfunded regardless of its cash, and this is the most common way a budget fails while being fully spent.
When the budget excludes salaries but a line still needs a euro figure for its hours, use the organisation's own loaded hourly rate. Absent one, the reference file gives the widely circulated multiplier and says what it is worth.
## Step 3 - Brainstorm allocation shapes before choosing one
Say explicitly that you are in brainstorming mode, and do not write a table yet.
First decide how much of last period survives. One rule overrides the choice: **never inherit silently** - any line whose share nobody can explain is zero-based this cycle, whichever mode you pick. Then choose the mode:
- **Zero-base the discretionary spend** - every line restarts at zero, is justified on this period's driver, then ranked and funded down the list until the envelope runs out. Do this when the driver changed, the budget owner changed, or the envelope moved by more than a fifth. The method is Peter Pyhrr's zero-based budgeting (Texas Instruments, early 1970s); it ranks with step 4's ordering, and that one ranking is also what step 7 cuts from, so the work is done once.
- **Budget incrementally** - keep the shape, argue the deltas. Do this when the driver is unchanged and last period's lines cleared their thresholds; re-justifying an evidenced line costs hours and produces the same answer.
Treat committed spend as a renewal decision keyed to its notice date, not as a line to re-justify mid-contract.
Build **two or three whole-budget candidates**, not one - a budget is a portfolio, and a single proposal hides the trade-off being made. Use [./references/allocation-archetypes.md](./references/allocation-archetypes.md) for each shape's pillar weights, its starve list and the situations it fits.
Shortlist from this default ordering, not from the reference's page order. It ranks the shapes on effort: hours, setup latency before first output, exit cost - and never on cash.
Cash is the thing being allocated here, so using it as the denominator would rank the cheapest shape first and answer a question nobody asked. Magnitudes only, no figures.
- **effort**, heaviest first: `community-led > enablement-first == content-compounding > field-and-events > ecosystem-and-sponsorship`
- **value**, outcome bought read over two years: `content-compounding > enablement-first > community-led > field-and-events > ecosystem-and-sponsorship`
- **efficiency**, value per hour committed: `enablement-first > content-compounding > field-and-events > ecosystem-and-sponsorship > community-led`
The one tie: enablement-first and content-compounding cost the same effort. Both convert into a standing weekly shift that outlives the period - a maintenance shift for one, a review shift for the other - and both need about a quarter before output runs at volume. Field-and-events beats sponsorship on efficiency because an event at least leaves behind material the program keeps; a sponsorship's whole return sits inside a surface someone else controls.
Barbell is deliberately absent from that ordering. It is a concentration rule applied on top of whichever shape wins, not a pillar mix of its own, so ranking it against the others would be false precision. Apply it by default anyway: most devrel work only pays past a threshold of consistency, so two pillars funded properly beat four funded at a quarter each.
**What this order starves: community-led.** Its payoff is slow and uneven, its staffing is permanent, and its exit cost is the only unrecoverable one in the list - so a shape ranked on efficiency alone never funds it, and the program keeps renting reach forever. Promote it when peer-to-peer questions already happen somewhere without you, a named person owns the venue permanently, and the funded driver is contributor community or retention rather than acquisition.
Present each candidate with:
- The pillar it over-invests in.
- Its three largest lines.
- What it deliberately starves.
- The hours it needs.
- The earliest signal it is working.
- The conditions under which it is the wrong shape.
Recommend one and say why. Get the budget owner to pick a shape before you price anything in detail - a wrong shape propagates into every line below it.
Adoption motion moves the order, so name it before recommending:
- **Individual-developer adoption** - money follows discoverability and time-to-first-success: docs and tooling, content, community answers, low-cost distribution. Events matter mostly as content and credibility sources, and the default ordering above already assumes this motion.
- **Company/enterprise buying** - money follows evaluation and proof: reference architectures, security and compliance material, field events where approvers actually stand, education and certification for implementation partners. This motion promotes field-and-events to the top of both value and efficiency; nothing else moves.
- Most programs face both. Rank them for this period instead of splitting evenly, and mark the lines that serve both so they get funded once.
Every ordering in this skill - the shapes here, the line kinds in step 4, the breadth-versus-depth call in the cost model - is a default, not a law. Each shifts with context and with who executes it, so re-rank against what you already know about this program before presenting one:
- A signed multi-year conference contract is committed spend, not a ranked option - the decision is renew-or-notice at its notice date, and the shapes are ranked over what is left.
- A team that cannot travel deletes field-and-events. Say it is deleted and name the constraint; never present it as the last-ranked shape.
- A budget that must be spent this period or is lost promotes rented reach and demotes every shape whose first readable signal lands after the lock date.
- An asset the default assumes away - a reviewer faster than anyone else's, a venue the company already owns, a maintainer already on staff - promotes the shape that consumes it, because its effort column is already paid.
## Step 4 - Set a return threshold per line, before funding it
Give every line one outcome unit and one number it must clear to keep its slot next cycle. Pick the unit from the pillar's own vocabulary:
- Events - cost per qualified conversation.
- Content - cost per published-and-reviewed piece.
- Community - cost per answered question or active contributor.
- Tooling - cost per unblocked developer.
Derive each threshold from a baseline the program already has, never from an aspiration. Where no baseline exists, fund the line as an experiment with a fixed window and a "we will know X by date Y" statement instead of a number.
Then rank the lines before you fund them - the order you write here is the order step 7 cuts from. Never rank two pillars against each other by cost per unit: the units measure different things, and the pillar that is easiest to instrument would win every round regardless of value. Cost per unit stays legitimate in exactly two comparisons - the same pillar across periods, and the same pillar across options (this conference or that one, agency or in-house).
Rank on effort instead, in magnitudes: hours, setup latency, exit cost. The line kinds below encode the three inputs that decide a devrel line's worth:
- Fit to the funded driver.
- Strength of the evidence that it worked before.
- Whether it is foundational to the others.
- **effort**, heaviest first: `new compounding line > new driver-fit line > rented reach > foundational maintenance > proven renewal == experiment`
- **value**, outcome bought: `new compounding line > foundational maintenance > proven renewal > new driver-fit line > rented reach > experiment`
- **efficiency**: `foundational maintenance > proven renewal > new driver-fit line > rented reach > experiment > new compounding line`
- **compliance cost**, by the review it triggers and the reversibility it costs: `multi-period sponsorship or foundation membership > multi-year event contract > hosted community venue > paid distribution > every other line`, which commits nothing past the period and needs no sign-off outside the team
The one tie: a proven renewal and an experiment cost the same effort because neither carries a setup pass - one is already running, the other is scoped to a fixed window on purpose.
**What this order starves: the new compounding line.** It is the highest-value kind on the list and it loses every cycle, because its effort is the heaviest and its payoff lands two quarters out - which is how a program spends on fast-acting lines forever and stays permanently tactical.
Promote it above rented reach when any of these holds:
- The user answered "compounding asset" at question 9.
- The envelope is flat or growing and neither of the last two periods funded one.
- A named person's hours are ring-fenced for it.
Once promoted, fund it across two periods or not at all - a compounding line cancelled at its first review bought nothing.
A line the user's constraints rule out is deleted from this order, never ranked last. Name it as deleted with the constraint that removed it, in step 5's ruled-out list. A ruled-out line parked at the bottom reappears as scope the moment the envelope moves.
One cross-pillar comparison adjusts the order without replacing it, borrowed from paid-media planning: put each pillar's share of the outcome next to its share of the budget.
- Fund up where outcome share exceeds budget share and the audience is still under-served.
- Question any pillar whose budget share has outrun its outcome share for two periods.
Comparing two ratios sidesteps the incompatible units that make a single cost-per-unit ranking meaningless.
Before you agree to grow a line, check that its result can actually be read. Score the program 1-3 on each of:
- The outcome is instrumented at all.
- The instrumentation predates the spend.
- Someone owns the number.
- There is an agreed attribution story for it.
Below half marks, hold the line flat and spend the increment on visibility first - a line nobody can read gets renewed on politics, whichever way its threshold went. The score and its cut-off are self-set, adapted from a paid-media measurement-maturity gate.
Present every threshold as repeatable rather than statistically rigorous - the framing paid-media practice uses for its own kill rules. Its job is to make the renew-or-drop conversation cheap and unemotional, not to prove causation; a threshold defended as proof invites a debate about attribution that DevRel measurement cannot win.
## Step 5 - Reserve, horizons and the unfunded list
- Hold **10-20% of discretionary spend unallocated** (self-set, but adjacent marketing-planning practice lands in the same band: a 10-15% contingency plus a testing reserve). The best opportunity of the year is rarely visible when the budget is written, and without a reserve every reactive request cannibalises a committed line.
- Split the allocated remainder across horizons: the bulk on compounding work already known to pay, a middle slice on scaling the one thing that is working, a small slice on genuine experiments that each carry a kill date. Any specific ratio proposed (70/20/10 is the familiar shape from marketing portfolio practice) is a proposal to argue with, not a devrel benchmark - say so when using it.
- Keep an explicit **unfunded list**: what was considered, ranked, and lost on the ranking, with one line on what would have to change to fund it. It stops rejected ideas from returning every month and gives the next cycle a ready shortlist.
- Keep a separate **ruled-out list**: lines a stated constraint removed - no travel, no agencies, a commitment past the period the user cannot make, an effort ceiling the line breaches. Name the constraint next to each. These were never ranked and do not return when the envelope moves; only the constraint lifting brings one back.
## Step 6 - Write the allocation
Produce one table plus the rules under it:
```markdown
| Line | Pillar | Cash | Hours/period | Owner | Buys | Threshold | Review | If it misses |
| -------------------------- | ------- | ------ | ------------ | ------------ | ---------------------- | ----------------------------------- | ------------------ | ---------------------------- |
| Flagship conference booth | Events | 28,000 | 240 | A. Rivera | 3 events, 2 staff each | ≤ 450 / qualified conversation | 2 weeks post-event | Renegotiate to workshop tier |
| Technical content pipeline | Content | 36,000 | 180 | S. Okafor | 24 reviewed pieces | ≥ 18 published, ≥ 500 sessions each | quarterly | Cut agency, halve volume |
| Reserve | - | 12,000 | - | budget owner | unallocated | - | quarterly | - |
```
Close the deliverable with:
- Totals against both envelopes.
- The horizon split.
- The reserve.
- The unfunded list.
- The ruled-out list.
- The review clocks.
- The reallocation triggers.
- The cut list.
- A five-sentence narrative the funder can repeat without you.
A full worked allocation, with a weak and a strong version of each section, is in [./references/allocation-example.md](./references/allocation-example.md).
Present it one section at a time and get agreement before moving on. Catching a wrong envelope at the first section costs a paragraph; catching it at the last costs the document.
## Step 7 - Set the clocks, the triggers and the cut list
Run three clocks, deliberately at different rhythms:
| Clock | Rhythm | Question |
| ------------ | ------------------------------------------------ | -------------------------------------------------------------- |
| Burn | monthly | Is cash going out at the planned rate, and are the hours real? |
| Line verdict | quarterly, or one outcome window after the spend | Did this line clear the threshold set before it was funded? |
| Envelope | annual cycle | What is next period's ask, and what evidence supports it? |
Write the reallocation triggers before the period starts, so a mid-year move is a rule firing rather than an argument:
- A line misses its threshold twice.
- The funded driver or its owner changes.
- A committed contract reaches its notice date.
- The person a line depends on leaves.
- An unplanned opportunity clears a higher bar than the weakest funded line.
Then write the **cut list**: step 4's efficiency order read from the bottom, applied to a 20% and a 40% reduction, each removal carrying its consequence in one sentence. Two overrides apply to that order:
- A foundational surface whose neglect is actively wrong (a stale doc, a broken sample, an unanswered venue) is cut last however it ranks.
- A compounding line promoted for two periods is not the first thing dropped, or the promotion was theatre.
Ruled-out lines never appear here; they left the plan before it was funded.
Roughly a quarter of surveyed programs lost budget in a single year, so this is a normal planning case. A team that volunteers a defensible order keeps control of the shape; a team that does not gets a flat percentage applied to every line, which starves the compounding work first.
Judge a first-year line against awareness-stage expectations, since recognition and relationships accumulate across editions. Treat a second consecutive miss as a drop signal anyway - compounding is not a licence to renew forever.
## Invocation examples
Match the ask to an entry point, and say which one you took.
| What the user says | Where to enter | What comes back |
| ------------------------------------------------------------------ | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| "We have 180K for devrel next year, help me split it." | Full workflow, step 1 | Envelope, two or three shapes, then the table and its rules |
| "Is 40% on events too much?" | Step 3, one shape only | The survey figure with its caveats, then the driver-and-motion test that decides it for this program |
| "Finance wants 20% out of devrel by Friday." | Step 7, cut list first | Ordered removals with a consequence each, and what must be protected |
| "Nobody will tell me the number." | Interview only | The questions, their owners, a date, and a percentage-based provisional split |
| "Was the conference worth it?" / "Should we even run a community?" | Route out | One event's return → `samber/developer-relations-skills@developer-event-sponsorship`; pillar selection → `samber/developer-relations-skills@devrel-strategy` |
Whatever the entry point, the artefact is one markdown document with these parts:
- Envelope (cash and hours, four money buckets).
- The line table.
- Horizon split.
- Reserve.
- Unfunded list.
- Ruled-out list.
- Review clocks.
- Reallocation triggers.
- Ordered cut list.
- A five-sentence funder narrative.
Sections the user's question does not touch can be one line each, but never silently dropped - a missing hours envelope or a missing cut list is exactly what makes a budget indefensible later.
## Quality gate
Hold the allocation to this bar and iterate until it passes. Report the check explicitly at the end.
- The envelope states whether salaries are inside it, and separates committed, discretionary, borrowed and in-kind.
- Total planned hours sit at or under the hours envelope after the 20-30% deduction; no line exceeds its owner's capacity.
- Every funded line names an owner, what it buys, one threshold, one review date and one miss action.
- Every threshold traces to a baseline, or the line is labelled an experiment with a kill date.
- The reserve is at least 10% of discretionary spend and is not quietly pre-committed.
- No pillar is compared to another pillar by cost per unit anywhere in the document, and no ranking uses a cash figure as its denominator.
- Every ordering names its axes, and every `==` carries the sentence that makes the two genuinely equal.
- The starved option is named at both levels - shape and line - each with the condition that promotes it.
- Lines a constraint removed appear as ruled out with the constraint named, never as the last row of a ranking.
- At most two pillars are funded above token level, unless the program is at scale stage with the capacity to prove otherwise.
- The unfunded list and the cut list are both non-empty, and the cut list is ordered.
- The narrative fits in five sentences and contains no devrel jargon.
- Every percentage and threshold in the document is tagged sourced, program baseline or self-set, and no self-set number is described as a standard.
An allocation that fails the hours line does not have a discipline problem. It has one line too many.
## Common failure modes
- **Allocating cash only.** The plan looks funded and the quarter still fails, because the hours were never counted. Price both.
- **Quoting the survey split as a target.** The published events/salaries/content/marketing shares come from 47 respondents on inconsistent bases and omit community, tooling and education entirely. Use them to show that a departure is deliberate, never as a benchmark.
- **Ranking pillars by ROI, or by cash per outcome.** Whichever pillar is easiest to instrument wins, and the program defunds the work that was carrying it. Rank on hours, latency and exit cost; cash is what the plan allocates, never what it divides by.
- **Parking a ruled-out line at the bottom of the ranking.** It reads as merely unaffordable, so it comes back as scope the next time the envelope moves. Delete it and name the constraint.
- **Spreading thin to keep everyone happy.** Four pillars at 25% clear no threshold. Concentrate and name what is starved.
- **No reserve.** The first unplanned opportunity eats a funded line, and the plan stops describing reality by month three.
- **Renewing by default.** A line that has missed twice is renewed because cancelling is awkward. That is what the written trigger exists to prevent.
- **Thresholds invented after the fact.** A number chosen once the result is known is a narrative, not a threshold.
- **Treating borrowed budget as owned.** The other team re-plans, and a core line vanishes mid-period.
- **Only a total for the cut scenario.** "We could absorb 20%" without an ordered list hands the ordering to someone who does not know what compounds.
- **Precision without a stated origin.** A "1.35× loaded-cost multiplier" or a "30/40/20/10 split" reads as authority precisely because it is specific, and gets quoted back for years after the guess behind it is forgotten. Say where each figure came from, or drop it.
- **Funding a line nobody can read.** Growing spend on an outcome that is not instrumented buys a renewal argument, not a result. Fix the visibility with the increment instead.
## References
- samber/developer-relations-skills@devrel-strategy for the program shape this budget funds.
- samber/developer-relations-skills@devrel-metrics for the measurement framework the thresholds borrow from.
- samber/developer-relations-skills@developer-event-sponsorship for splitting the event line.
- samber/developer-relations-skills@devrel-content-calendar for the content line's throughput.
- samber/developer-relations-skills@developer-community-launch for the community line's readiness gates.
- samber/developer-relations-skills@devrel-team-structure for who owns which budget.