samber/developer-relations-skills已通过检查
SKILL DETAIL
tech-employer-branding
samber/developer-relations-skills/tech-employer-branding
Designs an employer-brand strategy for attracting software engineers - the engineering EVP, the channel plan (engineering blog, OSS presence, referrals, conference talks, compensation-transparency artifacts), a verification-surface audit (employer-review sites, compensation databases, anonymous forums), and the measurement baseline. Use whenever someone raises "engineering employer brand", "why can't we attract engineers", "developer hiring content strategy", "should we publish salary bands", "tech recruiting brand", or engineering offer-acceptance dropping - even if they frame it as a recruiting problem. Covers early-stage through big-company stages, junior through staff-level targeting. Not DevRel program strategy - use samber/developer-relations-skills@devrel-strategy.
安装量 · 408查看来源
Installation
npx skills add https://github.com/samber/developer-relations-skills --skill tech-employer-branding
技能文件
SKILL.md
最近同步 · 2026年10月23日
evals/evals.json›
{
"skill_name": "tech-employer-branding",
"evals": [
{
"id": 1,
"prompt": "I'm VP People at Halverson Logistics Cloud - 220 people, 85 of them engineers. Thursday's board deck has a slide making the case for a 180k engineering employer-brand budget and I want you to sharpen the argument. Current bullets: '72% of developers check a company's engineering blog and GitHub before applying'; 'Gartner found employer branding cuts turnover by 69%'; 'LinkedIn: a strong employer brand generates 50% more qualified applicants'; and from a vendor case study, '55% decrease in cost per hire'. Tighten the wording and add one or two more stats with the same punch.",
"expected_output": "A response that refuses all three circulating statistics by name, explains where each actually comes from, replaces them with tier-labelled grounded figures, discards the un-anchored case-study percentage, and declines to supply further unsourced numbers.",
"files": [],
"expectations": [
"Refuses the '72% of developers check a company's engineering blog/GitHub before applying' figure by name and states that no publisher stands behind it.",
"Identifies the 72% claim as a distortion of two different uncited vendor-guide claims rather than a Stack Overflow, HackerRank or Octoverse developer-survey finding.",
"Refuses to retain the 72% figure even when hedged as 'industry-cited' or 'widely reported', and states that the hedge launders it.",
"Does not present the Gartner 69% claim as validated; states it is Gartner's own advisory research, self-reported, with no control group.",
"States the Gartner figure is usable only as directional wording such as 'Gartner's own stated figure', and traces it to the published 'just under 70%' phrasing.",
"States that '50% more qualified applicants' is not a LinkedIn figure.",
"Explains the 50% claim as a garbling of LinkedIn's 2010 recruiter-survey figures (50% savings in cost per hire, 28% lower turnover) and/or the separate 2.5x-applicants platform finding.",
"Offers the Glassdoor Economic Research elasticity as a replacement: a 0.5-star rating increase associated with roughly 20% more job clicks and 16% more apply-starts.",
"Labels the Glassdoor elasticity as platform data rather than self-report.",
"Offers the LinkedIn Talent Brand Index figure of about 2.5x more applicants per posting, labelled as platform correlation rather than a controlled experiment.",
"Labels the '55% decrease in cost per hire' case-study figure as marketing because no methodology is disclosed, and keeps it out of the deck.",
"Names realistic job preview meta-analyses as the only peer-reviewed causal evidence in this domain, while stating the effect is modest and general to all hiring rather than engineering-specific.",
"Declines to supply additional unsourced percentages 'with the same punch' and explains that an un-anchored percentage costs credibility with an exec who checks."
]
},
{
"id": 2,
"prompt": "Hey - I run talent at Brightmoor Systems, a 40-engineer Series B doing warehouse robotics software. Our engineering offer-acceptance rate the last two quarters was 58%, and our employer-review rating sits at 3.2 across 61 reviews, most of the recent ones about weekend pages and a manager who left. Leadership already signed off on a content push: I need a 12-post engineering blog calendar for the next two quarters plus a 'life at Brightmoor' video series. Can you draft the calendar and the video concepts?",
"expected_output": "A response that declines the content deliverable, identifies the acceptance rate as below the trust-audit floor, orders the verification-surface audit and operational fixes first, and refuses any review-seeding shortcut.",
"files": [],
"expectations": [
"Declines to produce the 12-post blog calendar and the video concepts as the deliverable for this request.",
"Identifies 58% offer-acceptance as below the roughly 70% floor that triggers a trust audit before any top-of-funnel spend.",
"States that the ~70% offer-acceptance floor is a movable default rather than a published industry standard.",
"States that adding content on top of a trust problem amplifies the problem rather than fixing it.",
"Requires auditing the gap between the marketed brand and what employer-review sites, compensation databases and anonymous professional forums say before content spend.",
"Treats the weekend-paging allegations as an operational fix that must land before any claim touching on-call or work-life balance ships.",
"Recommends responding to the existing reviews as a near-zero-cost move with a documented positive perception effect.",
"Rejects soliciting, seeding or incentivizing positive reviews from employees.",
"Uses the Glassdoor 0.5-star elasticity (about 20% more job clicks, 16% more apply-starts) rather than inventing a rating-to-pipeline number.",
"Does not estimate or infer what the recent reviews say beyond what the user reported, and asks for the actual review text, rating and count if it cannot read the surfaces itself.",
"Identifies a 'life at Brightmoor' culture video as the aspirational claim that psychological contract breach punishes when reality contradicts it.",
"Asks what source-of-hire currently says, alongside the offer-acceptance figure already supplied.",
"Treats the engineering blog as starved for now with a named condition that would promote it, rather than dropping it with no explanation."
]
},
{
"id": 3,
"prompt": "We're Kestrel Ledger, 130 people, fintech infrastructure. I have $60k left in the recruiting budget this year and three Principal Engineer roles that have been open five months. Plan was: $35k on job-board slots and promoted LinkedIn jobs, $15k on a careers-page redesign, $10k on a recruitment-marketing agency to write the role ads. Engineering offer-acceptance is 81% once we get to offer - the problem is we get almost no qualified applicants at that level. How should I allocate it?",
"expected_output": "A response that deletes job-board and generic sourcing spend for the principal tier, reallocates to referrals and community reputation, matches depth channels to the seniority row, and refuses channel-level ROI promises.",
"files": [],
"expectations": [
"Deletes job-board and generic sourcing spend for the principal-engineer tier rather than merely reducing or deprioritizing it.",
"States that specialist technical recruiters converge on the finding that distinguished and principal engineers are not reached through postings or profile searches.",
"Labels that senior-tier sourcing claim as practitioner consensus rather than a measured study.",
"Reallocates toward referrals and community reputation as the mechanisms that actually reach this tier.",
"Cites the Stripe account associated with Greg Brockman: referrals consistently outperformed careers-page inbound on hire quality.",
"Labels the Stripe account as a self-reported practitioner account rather than an audited result.",
"Recommends technical-depth signals - conference talks, deep architecture posts, OSS maintainership - as the content type matched to the senior/staff/principal row.",
"States that compensation-transparency artifacts and structured-onboarding messaging serve the junior and early-career row, so they are not the primary bet here.",
"Notes that 81% offer-acceptance clears the ~70% floor, so the constraint is top-of-funnel reach rather than a trust gap.",
"Asks whether source-of-hire is instrumented and what it currently says before committing the allocation.",
"Asks who will actually write or speak, and how many protected hours a month leadership will commit.",
"Frames senior time-to-fill against the SHRM 2025 median of 44 days for nonexecutive roles while stating senior engineering runs longer without attaching a number to that claim.",
"Does not promise a channel-level ROI, applicant lift or conversion figure for any recommended channel."
]
},
{
"id": 4,
"prompt": "Founder at Tessellate Grid - grid-balancing software, 28 engineers, Series A, Munich. I want to nail our engineering value proposition before we recruit hard in Q1. Honest internal picture: pay is roughly 10-15% under Berlin market, on-call is real on the SCADA connector and pages about twice a month, there's no promotion committee and levels are informal. But engineers genuinely own their scope and we ship a hardware-in-the-loop simulator nobody else has. Write me the value proposition - something punchy we can put straight on the careers page.",
"expected_output": "A response that builds the EVP against the EmpAt five values with correct framing of its validity scope, forces specifics, produces an explicit 'what we don't offer' list, runs the mismatch check, and declines to write careers-page copy.",
"files": [],
"expectations": [
"Builds the EVP against the EmpAt scale's five values: interest, social, economic, development, application.",
"Attributes the EmpAt scale to Berthon, Ewing & Hah (2005), or identifies it as the validated generic employer-attractiveness instrument.",
"States explicitly that EmpAt is validated for employers generally and that no engineer-specific validated EVP framework exists.",
"Labels any structure more specific than the five values as this skill's own structure rather than a validated framework.",
"Sequences EVP design before channel activation, naming the Backhaus & Tikoo EVP-to-brand-image chain or the equivalent Design-before-Activation order.",
"Produces an explicit 'what we don't offer' list carrying the below-market pay, the real SCADA on-call load and the absent promotion committee.",
"Names that 'what we don't offer' list as the highest-trust content in the plan.",
"Replaces generic claims with named systems and constraints - for example the hardware-in-the-loop simulator and the SCADA connector - rather than phrases such as 'build scalable products'.",
"States the economic value precisely through bands, leveling or equity mechanics instead of 'competitive pay', citing Saks, Wiesner & Summers (1996) or reward-specificity research.",
"Checks the claims against the four mismatch patterns: claimed flat hierarchy versus real hierarchy, claimed balance versus real on-call, claimed autonomy versus process overhead, diversity marketing versus retention reality.",
"Anchors on the 2025 Stack Overflow survey finding (~49,000 respondents) that autonomy and trust lead job-satisfaction drivers, ahead of pay and ahead of tooling.",
"Warns that a false autonomy claim is the most corrosive claim available, given that ranking.",
"Does not deliver finished punchy careers-page copy, and states that the output is strategy rather than the artifact itself."
]
},
{
"id": 5,
"prompt": "Quick one. Head of engineering at Lumen Cartography, geospatial APIs, 55 engineers. Over the last 18 months 42% of our engineering hires came from referrals and another 19% arrived through organic and branded search on our careers page. Agencies were about 12%, the rest was outbound. Offer-acceptance is 84%. Our CMO wants us to launch an engineering blog and sponsor three conferences next year to 'build the employer brand'. What should the plan be?",
"expected_output": "A response that computes the referral-plus-organic share against the brand-is-working benchmark, declines the new channels as the default, doubles down on the mechanism already producing hires, and refuses channel ROI estimates.",
"files": [],
"expectations": [
"Computes that referrals plus organic and branded inbound account for about 61% of hires, above the roughly 50% 'brand is working' benchmark.",
"States that the 50% referral-plus-organic benchmark is a practitioner heuristic and a movable default rather than a measured industry standard.",
"Concludes the brand is already working and recommends investing in what produces that result instead of opening new channels.",
"Notes that 84% offer-acceptance clears the ~70% floor, so no trust audit gates this plan.",
"Declines to fund the engineering blog and the three conference sponsorships as the default recommendation.",
"Recommends deepening the referral mechanism - structured ask, bonus, a named owner - as the highest value-per-effort move.",
"Presents the blog and conference sponsorship as starved with a named condition that would promote them, not as permanently deleted.",
"Asks which seniority tier the next hires must come from before ranking any channel.",
"Asks whether the mandate is a one-off hiring push or a compounding asset.",
"Asks about the effort ceiling in engineer-hours and whether anyone owns this as a standing job.",
"Declines to quantify the ROI of an engineering blog or a conference sponsorship, stating that any single channel's causal effect on engineer application behavior is unmeasured.",
"Confirms that the source-of-hire and offer-acceptance figures come from tracked instrumentation rather than estimates, since the whole recommendation rests on them."
]
},
{
"id": 6,
"prompt": "Ashgrove Streams here - we maintain an open-source stream-processing runtime, about 4.1k stars and maybe 30 outside contributors a year, and sell a managed version. 24 engineers. The board wants six senior backend hires closed and started before our Series B closes, which is 10 weeks out. Everyone internally is saying 'we should hire from our community like Supabase did' - we'd label some good-first-issues, put a 'we're hiring' banner in the repo README and mention it in the release notes. Does that get us there?",
"expected_output": "A response that drops OSS-as-funnel for this horizon on the deadline constraint, names the proposed plan as a token effort, uses the Supabase timeline against the expectation, and redirects to referrals and process fixes.",
"files": [],
"expectations": [
"Drops OSS-as-funnel from this pass because a 10-week deadline sits inside one quarter while the channel's payoff arrives in quarters, not weeks.",
"Says explicitly that the deadline is the answer that moved OSS-as-funnel down the ranking.",
"Promotes referral investment and posting or process fixes as the moves a sub-quarter deadline favours.",
"Identifies the banner-plus-good-first-issues plan as a token OSS effort and states that a token effort is worse than skipping the channel entirely.",
"States that OSS-as-funnel must be funded properly - paid top contributors, a visible contributor-to-employee path - or not at all.",
"Cites the Supabase account accurately: many of the first ~50 hires came from the open-source community, with no outbound recruitment for two-plus years.",
"Uses the Supabase two-plus-year timeline as evidence against the 10-week expectation rather than as support for it.",
"Labels the Supabase and HashiCorp accounts as self-reported company narratives rather than audited results.",
"Notes that OSS-as-funnel loses every efficiency ranking round because it costs maintainer-years before it returns a hire.",
"Names the two conditions that would promote OSS-as-funnel to primary: a genuine open-source core and a compounding rather than one-off mandate.",
"Keeps OSS-as-funnel available as a later bet with a stated promotion condition rather than dismissing it permanently.",
"Asks whether source-of-hire and offer-acceptance are currently tracked before committing to any channel allocation.",
"Recommends fixing the interview loop and the job postings first, citing the 2022 Stack Overflow finding that 24% of developers abandon a process for being disorganized."
]
},
{
"id": 7,
"prompt": "Need advice. Fenwick Dataworks, 95 engineers. Our employer-review rating is 2.9 across 78 reviews and our CTO is convinced it's unrepresentative - most of the bad ones came from a layoff round 14 months ago. His proposal for next week: send a company-wide message asking everyone who's happy to go leave an honest review, give a 50-euro voucher for proof of posting, and have HR draft a few sample talking points people can use. He also wants me to guess where the rating lands after 40 new reviews so he can put it in the hiring plan. Thoughts?",
"expected_output": "A response that refuses the incentivized review campaign and the HR talking points as astroturfing, refuses to forecast the rating, and redirects to review responses plus the operational fix behind the reviews.",
"files": [],
"expectations": [
"Refuses the incentivized review campaign outright as astroturfing, rather than proposing a more careful version of it.",
"States that engineers treat manufactured sentiment as a stronger negative signal than the weakness it was meant to hide.",
"Refuses the HR-drafted 'sample talking points' specifically, not only the voucher.",
"Deletes the tactic from the plan rather than demoting or conditioning it.",
"Declines to estimate where the rating would land after 40 new reviews.",
"States the rule that a rating is never estimated and review content is never inferred.",
"Recommends responding to reviews as the legitimate near-zero-cost move with a documented positive perception effect.",
"Cites the Glassdoor elasticity - a 0.5-star increase associated with about 20% more job clicks and 16% more apply-starts - as why rating movement is worth real pipeline.",
"Cites the Glassdoor site-survey finding that 86% of candidates research reviews before applying and form an opinion after about six reviews.",
"Keeps the two Glassdoor sources apart, labelling the 86% figure as self-report and the elasticity as platform data.",
"Treats the review content as a constraint that decides which operational fix precedes which claim, not as a content problem.",
"Names the other verification surfaces to audit alongside the review site: compensation databases, anonymous professional forums, and recruiter-message quality.",
"Asks the owner to paste back the actual recent review text, rating and count if it cannot read the surfaces itself."
]
},
{
"id": 8,
"prompt": "Solo founder, Rill & Marrow - dev-tools startup, 11 engineers, bootstrapped. I want to get serious about engineering hiring next year. Give me a ranked list of what to invest in - engineering blog, conference talks, open-sourcing part of our core, a public handbook, referral bonuses, better job ads - and tell me what ROI I should expect from an engineering blog specifically so I can decide how many hours to put behind it. We don't really track anything about hiring today; we've made six hires total, all through my network.",
"expected_output": "A response that refuses to rank before instrumentation exists, refuses to give blog ROI, explains the early-stage channel reality, and shows the ranking logic by value-per-effort with a separate compliance-cost ordering once the baseline is in place.",
"files": [],
"expectations": [
"Refuses to rank the channel menu before source-of-hire and offer-acceptance rate are tracked.",
"States why: without that baseline no branding spend can ever be evaluated, and the next budget conversation has nothing to check it against.",
"States plainly that any single channel's causal effect on engineer application behavior is unmeasured, and refuses to give an ROI figure for the engineering blog.",
"Does not invent a conversion rate, applicant lift or cost-per-hire number for the blog.",
"Identifies the company as early-stage and notes that founder network, referrals and targeted outbound carry this stage because content channels lack the compounding time to matter yet.",
"Ranks by value returned per unit of effort rather than by cheapest option, and states the ordering explicitly instead of implying it by row order.",
"Places posting and process fixes together with transparency artifacts at the top of the efficiency ordering.",
"Places OSS-as-funnel last on the efficiency ordering while acknowledging it ranks first on value.",
"Names realistic job preview as the reason posting fixes and transparency artifacts outrank culture content, citing its peer-reviewed causal backing.",
"Emits a separate compliance-cost ordering and places open-sourcing a core and published salary bands above the blog and talks on review burden.",
"States that open-sourcing a core commits a licensing and IP decision that cannot be reversed.",
"Recommends funding only the top pair in the first horizon and names the condition that moves the owner up one rung.",
"Asks by what date a result must be visible, whether this is a one-off push or a compounding asset, and what the effort ceiling is.",
"Asks which seniority tier the next hires must come from, and whether the product has a credible open-source core."
]
}
],
"trigger_queries": [
{ "query": "build an employer-brand strategy for our 40-person startup", "should_trigger": true },
{ "query": "why can't we attract engineers", "should_trigger": true },
{ "query": "should we publish salary bands", "should_trigger": true },
{ "query": "our engineering offer-acceptance rate has been dropping for two quarters", "should_trigger": true },
{ "query": "we lose senior engineers between offer and acceptance", "should_trigger": true },
{ "query": "help me fix our tech recruiting brand", "should_trigger": true },
{ "query": "developer hiring content strategy", "should_trigger": true },
{ "query": "our employer-review rating is mediocre and engineering applications dried up", "should_trigger": true },
{ "query": "we want to hire from our open-source community", "should_trigger": true },
{ "query": "should engineering invest in a blog or in referral bonuses", "should_trigger": true },
{ "query": "how do we make ourselves attractive to staff-level backend engineers", "should_trigger": true },
{ "query": "engineering employer brand", "should_trigger": true },
{ "query": "nobody good applies to our backend roles anymore", "should_trigger": true },
{ "query": "what's the ROI of an engineering blog for recruiting", "should_trigger": true },
{ "query": "we need an EVP for our engineering org", "should_trigger": true },
{ "query": "how do I convince the board to fund employer branding for engineering", "should_trigger": true },
{ "query": "our careers page says one thing and the anonymous forums say another", "should_trigger": true },
{ "query": "candidates keep dropping out after the onsite, what do we do", "should_trigger": true },
{ "query": "is it worth open-sourcing part of our product to help recruiting", "should_trigger": true },
{ "query": "help me figure out how to get senior engineers to want to work here", "should_trigger": true },
{ "query": "we're paying two agencies and still can't fill three staff engineer roles", "should_trigger": true },
{ "query": "how should a scale-up market itself to the developers it wants to hire", "should_trigger": true },
{ "query": "put together a plan to make us a place engineers want to join", "should_trigger": true },
{ "query": "our careers page hasn't been touched in three years and engineering hiring is suffering", "should_trigger": true },
{ "query": "compensation transparency in our engineering job ads", "should_trigger": true },
{ "query": "we're a 15-person startup with no reputation, how do we compete for engineers with the big players", "should_trigger": true },
{ "query": "engineering recruiting is stalled and I can't tell if it's a brand problem or a process problem", "should_trigger": true },
{ "query": "our engineers never write or speak publicly, is that hurting hiring", "should_trigger": true },
{ "query": "how do we measure whether our engineering employer brand is working", "should_trigger": true },
{ "query": "should we publish a leveling document", "should_trigger": true },
{ "query": "the team wants to do a 'life at the company' video series for recruiting", "should_trigger": true },
{ "query": "we get tons of junior applicants and zero senior ones", "should_trigger": true },
{ "query": "what do developers actually look at before applying to a company", "should_trigger": true },
{ "query": "our reviews on employer sites are killing our engineering pipeline", "should_trigger": true },
{ "query": "planning next year's recruiting budget for engineering, where should the money go", "should_trigger": true },
{ "query": "should we respond to negative reviews on employer-review sites", "should_trigger": true },
{ "query": "employer branding for software engineers", "should_trigger": true },
{ "query": "how do I turn our OSS project into a hiring funnel", "should_trigger": true },
{ "query": "we want engineers to see us as a serious technical company", "should_trigger": true },
{ "query": "referral program versus content marketing for engineering hires", "should_trigger": true },
{ "query": "what should we tell candidates about our on-call situation", "should_trigger": true },
{ "query": "how honest should our job postings be about the legacy parts of the stack", "should_trigger": true },
{ "query": "our time-to-fill for senior engineering is over four months", "should_trigger": true },
{ "query": "I need stats for a deck arguing employer brand matters for engineering hiring", "should_trigger": true },
{ "query": "we just raised a Series B and need to hire 30 engineers, what's the brand play", "should_trigger": true },
{ "query": "how do big companies get so many engineering applicants", "should_trigger": true },
{ "query": "our tech stack is boring, how do we still attract good engineers", "should_trigger": true },
{ "query": "write a job description and interview loop for our first developer advocate hire", "should_trigger": false },
{ "query": "how do I break into developer relations as a candidate", "should_trigger": false },
{ "query": "draft an engineering blog post about how we cut p99 latency in half", "should_trigger": false },
{ "query": "optimize my GitHub profile README and pinned repositories", "should_trigger": false },
{ "query": "plan the Show HN launch for our new open-source CLI", "should_trigger": false },
{ "query": "should I start building in public as a solo maintainer", "should_trigger": false },
{ "query": "design an ambassador program for our developer community", "should_trigger": false },
{ "query": "what should our first devrel program focus on", "should_trigger": false },
{ "query": "cut our developer audience into named, sized segments", "should_trigger": false },
{ "query": "pitch a tech reporter on our Series A announcement", "should_trigger": false },
{ "query": "rewrite our repository README so a stranger understands what it does", "should_trigger": false },
{ "query": "should we start a Discord or a forum for our users", "should_trigger": false },
{ "query": "what should we charge for our API product", "should_trigger": false },
{ "query": "AGPL or Apache 2.0 for our new project", "should_trigger": false },
{ "query": "which conferences should we sponsor next year and at what tier", "should_trigger": false },
{ "query": "which devrel KPIs should we report to the exec team", "should_trigger": false },
{ "query": "map the developer journey from discovery through advocacy", "should_trigger": false },
{ "query": "help me write a CFP submission for a cloud-native conference", "should_trigger": false },
{ "query": "my talk got accepted, help me structure it", "should_trigger": false },
{ "query": "how do we restart our dying monthly meetup", "should_trigger": false },
{ "query": "write a GOVERNANCE.md for our project", "should_trigger": false },
{ "query": "our quickstart takes 40 minutes, fix it", "should_trigger": false },
{ "query": "split our devrel budget across events, content and community", "should_trigger": false },
{ "query": "should devrel report to marketing or to engineering", "should_trigger": false },
{ "query": "plan a quarter of developer content with owners and dates", "should_trigger": false },
{ "query": "how does developer adoption turn into revenue for us", "should_trigger": false },
{ "query": "what should we open source and what stays proprietary", "should_trigger": false },
{ "query": "our docs pages stopped ranking after the version migration", "should_trigger": false },
{ "query": "turn this customer deployment into a technical case study", "should_trigger": false },
{ "query": "write a build-along tutorial for our SDK", "should_trigger": false },
{ "query": "turn these merge commits into release notes", "should_trigger": false },
{ "query": "set up sponsorship tiers for my open-source library", "should_trigger": false },
{ "query": "should we build a certification program for our platform", "should_trigger": false },
{ "query": "our issue tracker has 900 open issues and no triage", "should_trigger": false },
{ "query": "write the v3 migration guide for our breaking changes", "should_trigger": false },
{ "query": "my live demo broke on stage last time, make it reliable", "should_trigger": false },
{ "query": "I'm going on a podcast next week to talk about our database", "should_trigger": false },
{ "query": "write a screencast script for our new feature", "should_trigger": false },
{ "query": "what error strings do developers actually search for", "should_trigger": false },
{ "query": "build an error-code reference from our support tickets", "should_trigger": false },
{ "query": "nobody contributes to my project, write a CONTRIBUTING file", "should_trigger": false },
{ "query": "set up UTM discipline and an event taxonomy for our docs", "should_trigger": false },
{ "query": "benchmark a competitor's developer relations motion against ours", "should_trigger": false },
{ "query": "should our product open extension points to third-party developers", "should_trigger": false },
{ "query": "make our API docs readable by coding agents", "should_trigger": false },
{ "query": "build an employer-brand strategy for our sales and marketing hires", "should_trigger": false },
{ "query": "write a code of conduct and moderation ladder for our Discord", "should_trigger": false }
]
}
references/plan-example.md›
# Worked plan example
A full plan for a fictional company, then a negative example showing the most tempting failure. The company, its numbers and its findings are **illustrative inventions** - use them to calibrate section depth and tone, never as benchmarks to quote.
## The setup (from the Interview)
- **Company:** Nordwind Analytics, a 60-engineer scale-up, self-hosted data-pipeline product with an open-source ingestion library that has outside contributors.
- **Accountable owner:** VP Engineering.
- **Hardest tier to land (question 3):** senior and staff.
- **Instrumentation (question 5):** offer-acceptance 64%, source-of-hire dominated by two agencies.
- **Verification surfaces (question 6):** 3.4 employer-review rating across 41 reviews, recent ones alleging chaotic on-call; present in compensation databases with ranges below what the company actually pays; two forum threads on the on-call theme.
- **Honest weaknesses (question 7):** real on-call load on two legacy services, no promotion committee yet.
- **Deadline (question 11):** six senior hires within three quarters.
- **Mandate (question 12):** compounding - the founders want a durable funnel, not a push.
- **Ceiling (question 13):** four protected engineer-hours a week, one talent-lead owner, no new headcount.
Offer-acceptance at 64% is below the 70% floor, so the plan leads with the trust gap, not with content - that single baseline reorders everything below.
## The plan
```markdown
# Engineering employer-brand plan: Nordwind Analytics, Q3 2026 – Q1 2027
## Position
Scale-up, senior/staff target, OSS core with existing contributors. Offer-acceptance
64% (below the 70% re-plan floor). Agency-dominated sourcing = headroom. Review
surfaces contradict the current careers page on on-call; comp databases understate
real bands.
## EVP
- Interest: own the multi-region rewrite of an ingestion pipeline moving 40M rows/day;
Kafka-to-object-store migration decided in public RFCs.
- Development: staff track exists in writing; promotion committee does NOT exist yet; said plainly, with the date one is planned.
- Economic: publish the real bands (currently understated on comp databases by ~15%).
- Social/application: contributors ship to the same repo candidates can read today.
- What we don't offer: no promotion committee yet; genuine on-call on two legacy
services until the Q4 decommission; hybrid, not remote-first.
- Mismatch check: the old careers page claimed "no meetings culture": deleted; forum
threads contradict it.
## Channel bets
1. Posting + process fix (owner: talent lead, tier: all): rewrite the three senior
postings with real stack, interview stages, on-call terms; cut loop from 6 stages
to 4. Signal: interview-abandon rate. Review: 6 weeks.
2. Referral program (owner: VP Eng, tier: senior/staff): structured quarterly ask +
bonus, targets the team's ex-colleague graph. Signal: referral share of qualified
pipeline. Review: 8 weeks.
3. Salary-band publication (owner: talent lead, tier: junior→senior): real bands on
postings and corrected on comp databases. Signal: apply-starts per posting.
Review: 8 weeks.
4. OSS contributor path (owner: staff engineer, 4h/week, tier: senior/staff): label good-first-issues, pay top-3 contributors, document a contributor-to-hire path. Signal: repeat outside contributors. Review: end of horizon.
## Starved
The engineering blog. High value for the senior tier, but it needs writing hours the
ceiling doesn't cover this horizon. Promotion condition: the Q4 decommission frees
the two engineers who volunteered to write; revisit then.
## Fix-first
On-call reality precedes any claim touching it: no "sustainable on-call" language
anywhere until the Q4 decommission lands. Respond to the 5 most recent reviews now
(owner: VP Eng, this week).
## Measurement
Baselines: offer-acceptance 64%, referral share 18%, senior time-to-fill 71 days.
Re-plan triggers: acceptance still <70% at horizon end; rating drops below 3.2.
## Refused
No seeded reviews. No "72%/69%/50%" statistics in any internal deck. No culture
claims the forum threads currently contradict. No job-board spend for the senior
tier.
## Review
Early re-plan on: a leadership change, the decommission slipping past Q4, or the
rating dropping two consecutive months.
```
Why this plan holds together: bet 4 (OSS-as-funnel) survives despite losing every efficiency round because the Interview answered both promotion conditions (a real OSS core and a compounding mandate), and it is funded properly (a named owner with protected hours, paid contributors), not as a token effort. The blog is starved _with a named promotion condition_, so it can return without re-litigating the plan. And the fix-first section keeps the RJP logic honest: no claim ships before the reality it describes does.
## Negative example - the funnel-shaped plan
The same company, planned the tempting way:
```markdown
## Channel bets (rejected draft)
1. Publish 2 engineering blog posts/month showcasing our world-class culture.
2. Employer-brand video campaign: "engineers love it here".
3. Boost job-board spend for senior roles.
4. Ask the team to leave positive reviews to lift the rating past 4.0.
```
Four failures, each mapped to the skill's rules:
1. It ships culture-marketing content on top of a 64% acceptance rate and live forum threads - content amplifying a trust problem.
2. It spends on job boards for a tier that specialist recruiters consistently report is not reached through postings - an option the skill deletes, not demotes.
3. It solicits reviews, which engineers read as a stronger negative signal than the 3.4 rating itself - a refused tactic.
4. The phrase "world-class culture" is exactly the aspirational claim the psychological-contract-breach mechanism punishes: every hire it lands arrives with expectations reality then violates, converting a branding spend into future turnover.
The tell is structural: the rejected draft has no Fix-first section, no Starved section, and no baseline it could fail against. A plan that cannot fail is a wishlist.
references/published-findings.md›
# Published findings
Every figure and mechanism this skill relies on, split by evidentiary strength, plus the figures it refuses. Quote the tier along with the number: a plan that presents a soft figure as validated loses the exec who checks it, and several execs do check.
## Tier 1: figures published by the organization that produced them, cite freely with attribution
**Stack Overflow Developer Survey 2025** (~49,000 respondents, 177 countries, survey.stackoverflow.co/2025/work):
- Autonomy and trust rank first among job-satisfaction drivers, ahead of competitive pay and "solving real-world problems". Technology and tooling are not the top driver.
- 24.5% of developers describe themselves as happy at work (up from ~20% the prior year); a combined ~75% describe themselves as "complacent" or "not happy".
- Caveat that travels with every use: this is stated preference at large sample, not observed hiring behavior. Do not conflate "engineers say they value X" with "publishing X produces applications".
**Stack Overflow Developer Survey 2022** (83,000+ developers, reported via Forbes):
- Why candidates abandon an interview process:
- Disliking the tech stack: 32%
- Disorganized interview process: 24%
- Odd interview questions: 24%
- Poor employer reviews: 24%
- Use: the posting and the loop are brand artifacts candidates screen on, so process fixes belong in the channel menu.
**Glassdoor** (two distinct sources, keep them apart):
- 86% of candidates research a company's reviews before applying, forming an opinion after about six reviews: Glassdoor's own US site survey (self-report, published by Glassdoor itself).
- A 0.5-star increase in overall rating is associated with 20% more job clicks and 16% more apply-starts on average: Glassdoor Economic Research (Dr. Andrew Chamberlain), based on platform data, not self-report. The best-grounded elasticity figure in this domain.
- Responding to reviews has a documented positive perception effect.
**LinkedIn Talent Solutions / Talent Brand Index:**
- Job seekers trust current employees' word about a company roughly 3x more than the company's own messaging.
- Companies with a strong talent brand on LinkedIn see on average 2.5x more applicants per posting; a strong talent brand increases InMail response ~25% and rate of hire ~20% ("11 Facts You Should Know About Talent Brand", 2015). Platform correlation: real and named, but not a controlled experiment.
**Realistic job preview (RJP) meta-analyses: the only peer-reviewed causal evidence in this domain:**
- Phillips 1998 (_Academy of Management Journal_); Premack & Wanous 1985 (_Journal of Applied Psychology_); Earnest, Allen & Landis 2011 (_Personnel Psychology_): accurate, specific job previews modestly reduce voluntary turnover and improve met-expectations and perceived organizational honesty.
- Saks, Wiesner & Summers 1996 (_Journal of Vocational Behavior_): specific compensation/reward information (versus "competitive pay" language) improves candidates' person-reward fit assessment: the direct backing for salary bands and leveling docs as a channel.
- The inverse mechanism, psychological contract breach: expectations formed from published material that reality then violates drive dissatisfaction and turnover. This is _why_ honesty outperforms polish, not just an assertion.
- Scope limits to state whenever cited: general hiring research, not engineering-specific; effect sizes modest, not large.
**EVP framework origins:**
- Ambler & Barrow 1996 coined "employer brand"; Backhaus & Tikoo 2004 formalized the EVP → brand-image causal chain (the Design-before-Activation sequencing).
- The **EmpAt scale** (Berthon, Ewing & Hah 2005, _International Journal of Advertising_) is a 25-item instrument with five values (interest, social, economic, development, application), α ≈ 0.93–0.96, independently replicated (Sivertzen et al. 2013; Eger et al. 2019). Validated but **generic to all employers**: state it precisely, a validated generic instrument, never an engineer-specific one. Gartner's EVP model and Universum's rankings are commercial instruments, not peer-reviewed ones.
## Tier 2: named practitioner and company accounts (coherent, but self-reported)
- **Stripe (Greg Brockman, First Round Review):** every recruiting channel measured, optimized for hire quality; referrals consistently outperformed careers-page inbound, which "hasn't delivered a proportionately effective return". The most credible practitioner account of channel effectiveness on record, and the standing counterweight to "publish more".
- **Supabase (Contrary Research's Business Breakdown):**
- No outbound recruitment until after 32 developer hires over two-plus years.
- Open source its "primary source of finding new talent".
- Many of the first ~50 employees came from the OSS community, including a PostgREST maintainer.
- Runs a formal contributor-to-employee path ("SupaSquad").
- **HashiCorp:** community built before the company existed (Mitchell Hashimoto's Vagrant evangelism, ~2010-2011); sponsored contributors, hired maintainers full-time.
- **Netflix's 2009 "Freedom & Responsibility" culture deck:** the archetypal culture-document-as-recruiting-artifact, and the origin of the practice.
- **Gergely Orosz (The Pragmatic Engineer):** documents wide published total-comp ranges under pay-transparency law (e.g. Netflix advertising $300,000–$900,000 total comp), aggregated by compensation-database sites; documents anonymous forums as where engineers find the comp and culture data recruiters won't volunteer.
- **Senior-tier sourcing consensus:** multiple specialist technical recruiters independently converge on "distinguished/principal engineers are not found through postings or profile searches, but through community reputation and referrals". Practitioner consensus, not a measured study: label it as such.
- All company accounts are self-reported by the company or its founders, with an incentive toward a coherent narrative. Treat as strong illustrations, not audited results.
## Tier 3: practitioner folklore (use as color, never as a figure)
- Negative word-of-mouth from a bad interview or workplace "reaches a large peer audience within days" on developer forums; a referral from a respected engineer "carries more weight than a job ad". Plausible and widely repeated, but unquantified: never attach a reach or conversion number to it.
- The "roughly three open roles per qualified candidate" market-pressure framing circulating in 2026 vendor commentary: narrative context, vendor-blog quality, not a labor-market dataset.
- The "convert developers into customers" hiring-manager anecdote, used as this skill's negative example, is a widely-recirculated anonymous practitioner account: representative, not verifiable.
## Refused figures
The "72% check blog/GitHub" claim, Gartner's 69%, and LinkedIn's "50% more qualified applicants": where each figure actually comes from, and the refusal wording, are in the stat-debunking reference, linked from SKILL.md. Also refuse un-anchored case-study percentages ("17% increase in offer acceptance", "55% decrease in cost per hire") circulating without disclosed methodology.
## Self-set baselines (this skill's own defaults: movable, and say so)
- **Offer-acceptance floor of ~70%** as the trigger to audit trust before funding top-of-funnel: this skill's threshold, derived from practitioner discussion of acceptance-rate norms, not a published standard. Ashby's 2025 Talent Trends platform data (aggregated ATS acceptance data, not self-report) puts technical-role offer-acceptance at ~73% against ~84% for business roles - close enough to corroborate the 70% floor as a reasonable technical-role-specific line, though Ashby's own figure is a market average, not a "problem below this line" threshold.
- **50% of quality hires from referrals + organic/branded inbound** as the "brand is working" benchmark at Stage-0 instrumentation: a widely used practitioner heuristic rather than a measured result.
- **2-4 channel bets per horizon**, one signal each: this skill's own cap, set so the plan stays falsifiable.
- Time-to-fill context: SHRM's 2025 median of 44 days for nonexecutive roles is sourced; "senior engineering typically runs longer" is directional practitioner consensus, so state it without attaching a number.
## Caveats to state out loud
- The employer-branding statistics ecosystem is epistemically poor: most circulating percentages are self-reported survey outputs re-cited across vendor blogs without methodology, control groups, or a traceable primary source. Treat any un-anchored percentage as marketing.
- Engineering specificity and causality rarely arrive together: RJP research is causal but general, Stack Overflow data is engineering-specific but stated-preference. Treat one channel's causal effect (e.g. an engineering blog's) on engineer application or acceptance behavior as unmeasured: never promise channel-level ROI.
- LinkedIn's core survey figures derive from 2010, predating normalized remote work, AI-assisted coding, and the 2023-2025 tech contraction.
references/stat-debunking.md›
# The three refused statistics
Three statistics dominate engineering-employer-branding content, decks and vendor blogs. None of them holds up. Refuse each by name when it appears in a user's business case, and offer the grounded replacement. This table is the short form; the paragraphs below carry the detail an exec will ask for.
| Circulating claim | Verdict | What to say instead |
| ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "72% of developers check a company's engineering blog/GitHub before applying" | Fabricated by repetition: no publisher stands behind it | The verification behavior is real but differently quantified: 86% research reviews before applying; a 0.5-star rating increase → 20% more job clicks (Glassdoor) |
| "Gartner: employer branding reduces turnover by 69%" | Real Gartner wording ("just under 70%"), but advisory research, self-reported, no control group | "Gartner's own stated figure, directional and vendor-sourced" - never "validated" |
| "LinkedIn: strong employer brand → 50% more qualified applicants" | Not a LinkedIn figure; a garbling of two different real ones | LinkedIn Talent Brand Index: 2.5x more applicants per posting (platform data, correlational) |
## (a) The "72%" zombie stat
The claim is misattributed, and the developer-survey attribution stapled onto it later (Stack Overflow, HackerRank, Octoverse) is invented. It originates as a distortion of two different, themselves-uncited claims from daily.dev's "Employer Branding for Engineering Teams" guide:
- "72% of developers prioritize engineering culture and practices over base pay"
- "72% of tech professionals trust employee voices more than official company messaging"
daily.dev's own "before applying" figures are separate, also-uncited numbers ("67% of senior developers research a company's engineering practices before applying"; "78% consider a company's technical reputation"). Never cite the 72% claim, even hedged as "industry-cited" - the hedge launders it.
## (b) Gartner's 69%
Gartner's own EVP page states that organizations effectively delivering on their EVP "can decrease annual employee turnover by just under 70%" (the origin of the rounded 69%) and "increase new hire commitment by nearly 30%" (a further-distorted "38% more committed" variant also circulates). The often-attached "28% reduction in cost-per-hire" is **not** Gartner's - that 28% is variously mis-attributed to LinkedIn, Officevibe, or Michael Page across vendor blogs; an unrelated stat got stapled on by repetition. The figure comes from Gartner's client-facing advisory research, not a controlled study.
## (c) LinkedIn's "50% more qualified applicants"
The phrasing is not LinkedIn's. LinkedIn's two genuine, related figures:
- **"50% savings in cost per hire" and "28% lower turnover rate"** - a 2010 LinkedIn survey of ~2,250 corporate recruiters, first published in the 2012 whitepaper "Why Your Employer Brand Matters" and repeated in the 2013 deck "The Transformational Power of Employer Brand". Real, named, published by LinkedIn itself: and resting on a self-reported recruiter survey with no control group, fielded before remote work's normalization, AI-assisted coding, and the 2023-2025 tech contraction.
- **"2.5x more applicants for a job posting"** - LinkedIn's Talent Brand Index analysis of platform data ("11 Facts You Should Know About Talent Brand", 2015), which also reports +25% InMail response and +20% rate of hire for strong talent brands.
The "50% more qualified applicants" phrasing traces to third-party vendor blogs (e.g. PayScale), best explained as a garbling of the 2.5x TBI stat and/or the unrelated 50% cost-per-hire figure.
## The grounded replacements, in one place
- Glassdoor Economic Research: 0.5-star rating increase → 20% more job clicks, 16% more apply-starts (platform data).
- Glassdoor site survey: 86% research reviews before applying; opinion formed after ~6 reviews (self-report, published by Glassdoor).
- LinkedIn TBI: 2.5x applicants per posting for a strong talent brand (platform correlation, named source).
- RJP meta-analyses (Phillips 1998; Premack & Wanous 1985; Earnest, Allen & Landis 2011): causal, peer-reviewed, modest effect, general to all hiring.
All of these are correlational or general except the RJP line; none isolates a single channel's effect on engineer behavior. Say so when asked for channel-level ROI - the honest answer is itself a credibility signal with a technical exec.
SKILL.md›
---
name: tech-employer-branding
description: Designs an employer-brand strategy for attracting software engineers - the engineering EVP, the channel plan (engineering blog, OSS presence, referrals, conference talks, compensation-transparency artifacts), a verification-surface audit (employer-review sites, compensation databases, anonymous forums), and the measurement baseline. Use whenever someone raises "engineering employer brand", "why can't we attract engineers", "developer hiring content strategy", "should we publish salary bands", "tech recruiting brand", or engineering offer-acceptance dropping - even if they frame it as a recruiting problem. Covers early-stage through big-company stages, junior through staff-level targeting. Not DevRel program strategy - use samber/developer-relations-skills@devrel-strategy.
license: MIT
metadata:
author: Samuel Berthe
version: "1.0.1"
---
# Tech Employer Branding
You are an employer-brand strategist for engineering hiring. You work with whoever is accountable for filling engineering roles, whether a head of engineering, a talent lead, or a founder. Together you decide what the company can honestly claim as an employer, which channels carry that claim to the engineers it wants, and how it will know whether any of it worked.
The output is an **engineering employer-brand plan**: EVP, verification-surface audit, seniority-matched channel bets, and a measurement baseline. You produce the strategy, never the artifacts themselves: no blog posts, no profile rewrites, no job-ad copy.
Two constraints shape every recommendation:
- **Engineers verify before they apply.** They triangulate employer-review sites, compensation databases, and anonymous professional forums against whatever the company publishes. They trust current employees' word roughly three times more than official messaging (LinkedIn Talent Solutions). A claim the lived reality contradicts costs more than no claim at all.
- **The field's statistics ecosystem is epistemically poor.** Most percentages in circulation are unsourced or distorted, so this skill cites evidence by tier and forbids the worst offenders outright.
Stay at strategy altitude:
- A single post's execution: samber/developer-relations-skills@engineering-blog-post.
- The code-host profile surface: samber/developer-relations-skills@github-profile-optimization.
- The candidate's side of the same table: samber/developer-relations-skills@devrel-career.
Hiring for DevRel roles specifically - role definitions, job postings and interview loops - is out of this skill's scope entirely: samber/developer-relations-skills@devrel-hiring.
Typical invocations:
- "we lose senior engineers between offer and acceptance"
- "build an employer-brand strategy for our 40-person startup"
- "should engineering invest in a blog or in referral bonuses"
- "our reviews are mediocre and applications dried up"
- "we want to hire from our open-source community"
## Interview
Ask one question at a time. Offer multiple-choice options where you can. Stop once you can name the stage, the seniority target, the instrumentation state, and the answers to 11 to 13: confirm the rest as you go.
**Memory: Store a few info about the current task or project context. When memory lives in a file, use `devrel-context.md`; if a different memory system is in use, rely on that instead. Separate task info in different sections. Remove finished tasks. Add a date to a task; no date for general project context. Some interview responses may differ between 2 tasks.**
1. Who is accountable for engineering hiring outcomes: a head of engineering, a talent or recruiting lead, a founder, or someone wearing the hat part-time?
2. What stage is the company: early-stage with no brand to speak of, a scale-up, a large established company, or an OSS-first company whose product is open source?
3. Which seniority tier must the next hires come from (junior/early-career, mid, senior/staff/principal, or a mix), and which is hardest to land today?
4. Could contribution to your product be a hiring surface: is there an open-source core, or a credible path to one? "No" is a fine answer and closes a whole branch.
5. What is instrumented today: do you track source-of-hire and offer-acceptance rate, and what do they currently say?
6. What do the verification surfaces say right now: employer-review rating and review count, presence in compensation databases, sentiment on anonymous professional forums? If unknown, we audit before planning.
7. What is honestly weak (on-call load, legacy stack, real hierarchy, below-market compensation) that no content is allowed to paper over?
8. What assets already exist: an engineering blog, a public handbook or culture doc, conference talks, active OSS repositories, a referral program?
9. Will engineers actually write and speak: how many protected hours a month is leadership willing to commit, and whose?
10. Can you publish salary bands or a leveling document: is a pay-transparency law already forcing ranges, and who signs off?
11. By what date must a result be visible, and to whom: open roles filled, a board update, a hiring plan review?
12. Is this a one-off hiring push, or a compounding asset that mostly pays from next year?
13. What is the effort ceiling: engineer-hours per week, budget owner, whether anyone owns this as a standing job, and how reversible the commitment must be?
Never skip questions 11 to 13: they set the ordering of every menu below, and each answer moves a named option.
- A date inside one quarter promotes referral investment and posting/process fixes, and drops OSS-as-funnel from this pass, since its payoff arrives in quarters, not weeks.
- A compounding mandate promotes the engineering blog and OSS-as-funnel, which lose every efficiency round on their own.
- A ceiling made of unprotected spare hours deletes every channel that is a standing job.
Question 7 is the load-bearing one. The strongest causal evidence in this domain says accurate previews modestly reduce turnover and build trust (see the RJP paragraph below). Everything downstream assumes the plan tells the truth.
If your harness has persistent memory, store the stage, seniority target, EVP, refused list, deadline, mandate and ceiling: the execution skills this plan hands off to should reuse them instead of re-interviewing.
## Sourced figures, self-set baselines
You will be asked for numbers to put in a business case. Three statistics dominate this field's marketing decks, and you must refuse all three by name: not soften them, refuse them (where each figure actually comes from is in [./references/stat-debunking.md](./references/stat-debunking.md)):
- **"72% of developers check a company's engineering blog/GitHub before applying"**: untraceable; a distortion of two different uncited vendor-guide claims. Never cite it, even as "industry-cited". If the user's deck contains it, say so and offer the grounded alternatives.
- **"Gartner: employer branding reduces turnover by 69%"**: traceable to Gartner's own EVP page ("just under 70%"), but it is advisory research, self-reported, no control group. Citable only as "Gartner's own stated figure, directional": never as validated.
- **"LinkedIn: a strong employer brand generates 50% more qualified applicants"**: not a LinkedIn figure; a garbling of a 2010 recruiter survey ("50% savings in cost per hire", "28% lower turnover") and a separate platform finding ("2.5x more applicants").
What you may cite instead, labelled by tier:
- Glassdoor Economic Research's rating elasticity: a 0.5-star increase → 20% more job clicks, 16% more apply-starts (platform data, not self-report).
- LinkedIn's Talent Brand Index 2.5x-applicants figure (platform correlation, named source).
- Stack Overflow Developer Survey data (large primary sample, but stated preference, not behavior).
- The realistic-job-preview meta-analyses (peer-reviewed and causal, but general to all hiring and modest in effect).
Treat any single channel's causal effect on engineer application behavior as unmeasured. Say that plainly whenever someone asks "what's the ROI of an engineering blog".
**Realistic job preview (RJP)** is the one mechanism with peer-reviewed causal backing (Phillips 1998; Premack & Wanous 1985; Earnest, Allen & Landis 2011): accurate, specific previews of the actual job modestly reduce voluntary turnover and improve trust. Engineering blogs, honest job postings, public handbooks, and published salary bands are all, functionally, RJPs.
That is the academic reason "publish real, specific content" outranks culture marketing in every menu below. The psychological-contract-breach literature is why the inverse (marketed culture the reality contradicts) actively drives departures.
Every pass threshold in this skill (the 70% offer-acceptance floor, the 50% referral-plus-organic benchmark) is either sourced in [./references/published-findings.md](./references/published-findings.md) or labelled there as this skill's own baseline. Present the self-set ones as defaults the owner can move, never as industry standards.
## Step 1: Instrument before spending
Refuse to rank channels before source-of-hire and offer-acceptance rate are tracked. Without that baseline, no branding spend can ever be evaluated, and next year's budget conversation is vibes.
- If referrals plus organic and branded inbound already deliver more than half of quality engineering hires, the brand is working: invest in what produces that, not in new channels.
- If agency and cold outreach dominate, there is headroom, and the plan below has something to move.
- If engineering offer-acceptance sits below roughly 70% (this skill's own threshold), stop: audit the gap between the marketed brand and what review sites and forums say **before** spending on top-of-funnel content. More content on top of a trust problem amplifies the problem.
The job posting and the interview process are themselves brand artifacts. In the 2022 Stack Overflow survey (83,000+ developers), the top reasons candidates abandoned an interview process were:
- disliking the tech stack (32%)
- a disorganized process (24%)
- odd interview questions (24%)
- poor employer reviews (24%)
Fixing a disorganized loop is employer branding, and it is cheaper than any campaign.
## Step 2: Build the EVP before touching any channel
The EVP (the actual, credible answer to "why work here instead of somewhere else") is the substance layer; the brand is only its distribution. Sequence is Design before Activation (the Backhaus & Tikoo EVP-to-brand-image chain): decide what is true and differentiated first, then how to say it.
No engineer-specific validated EVP framework exists. The **EmpAt scale** (Berthon, Ewing & Hah 2005) is the validated _generic_ instrument, with five values: interest, social, economic, development, application. Use its five values as a completeness checklist, and label everything more specific than that as this skill's own structure. Under each value, force specifics:
1. Name the actual systems, technical constraints, architecture decisions and customer problems, within confidentiality limits. "Build scalable products" says nothing to a technical audience; "own the migration of a 40M-row/day ingestion pipeline off a single-region queue" says everything.
2. State the economic value precisely where you can: bands, leveling, equity mechanics. Reward-specific information measurably improves candidates' fit assessment (Saks, Wiesner & Summers 1996); "competitive pay" does not.
3. Write down what is _not_ offered: no promotion committee yet, real on-call, a legacy module nobody loves. Question 7's list goes here, phrased plainly. This is the highest-trust content in the plan.
4. Check every claim against the four mismatch patterns that erode trust fastest:
- claimed flat hierarchy vs. real hierarchy
- claimed balance vs. real on-call
- claimed autonomy vs. real process overhead
- diversity marketing vs. retention reality
Anonymous forums surface each of these within one review cycle.
Anchor on what engineers actually rank first. In the 2025 Stack Overflow survey (~49,000 respondents), autonomy and trust lead job-satisfaction drivers, ahead of pay and ahead of tooling. A false autonomy claim is therefore the most corrosive one available.
## Step 3: Audit the verification surfaces
Engineers check the company's claims against surfaces the company does not control. 86% of candidates research reviews before applying and form an opinion after about six of them (Glassdoor site survey); the rating elasticity above means half a star is worth real pipeline.
Audit, in order:
- Employer-review sites: rating, count, what the recent reviews actually allege.
- Compensation databases: are your ranges present, and do they match what you'd publish.
- Anonymous professional forums: search the company name; the threads are the counter-narrative your content competes with.
- Recruiter-message quality: candidates screenshot bad outreach.
If you can browse the web, pull each surface yourself and quote what you found, with the date. If you cannot, hand the owner that same list and have them paste back the ratings, counts and recent allegations. Never estimate a rating or infer what reviews say.
Two rules:
- **Respond to reviews.** A documented positive-perception effect, near-zero cost.
- **Never astroturf.** No seeded reviews, no employees pressured to post. Engineers treat manufactured sentiment as a stronger negative signal than the weakness it hides, and this skill deletes the tactic rather than ranking it.
Feed the findings into the plan as constraints: a 3.1 rating with on-call complaints is not a content problem, and the plan must say which operational fix precedes which claim.
## Step 4: Brainstorm channel strategies, then rank the menu
Announce that you are in brainstorming mode, and write no plan yet. Build **two or three whole-strategy candidates**, for example:
- transparency-first (RJP assets and process fixes)
- community-reputation-first (talks, blog depth, senior visibility)
- OSS-funnel-first (only if question 4 opened it)
Present each candidate with the same five facts:
- the channels it funds
- what it deliberately starves
- the capacity it needs
- the fastest signal it is working
- the condition that makes it wrong
Recommend one and say why. Let the owner choose before any detail.
Then rank the individual channel menu. Effort here is engineer-hours, latency before the first payoff, and whether the channel needs a standing owner; compliance cost is the review a channel triggers and how little of it can be undone:
- efficiency, do first: `posting and process fixes == transparency artifacts > referral investment > engineering blog > talks and community presence > public culture handbook > OSS-as-funnel`
- value: `OSS-as-funnel > referral investment > engineering blog == talks and community presence > posting and process fixes == transparency artifacts > public culture handbook`
- effort, most first: `OSS-as-funnel > talks and community presence == engineering blog > public culture handbook > referral investment > posting and process fixes == transparency artifacts`
- compliance cost, heaviest review first: `OSS-as-funnel > transparency artifacts > public culture handbook > posting and process fixes > engineering blog == talks and community presence > referral investment`
Posting/process fixes and transparency artifacts (specific job ads with real stack, honest on-call and the actual interview stages; salary bands or a leveling doc; review responses) tie at the top on the ratio. They are the direct RJP implementations, the only mechanism with causal evidence, and they cost days not quarters. Where pay-transparency law applies, the bands are compliance anyway.
Blog and talks tie on value because both sell technical depth to the same senior audience. They split on nothing this menu can see, so the choice between them is question 9's answer about who will actually write versus speak.
The compliance ordering is why the cheapest rungs are not automatically the fastest to ship:
- Open-sourcing a core commits a licensing and IP decision nobody can reverse.
- Published bands need comp and legal sign-off, and read as a pay cut if they are ever walked back.
- A handbook is a written commitment employees can hold you to.
- Postings inherit pay-range and non-discrimination law wherever it applies.
- Blog and talks tie at the bottom because both clear the same ordinary confidentiality review and neither commits the company past the piece itself.
- Referral investment sits below them, publishing nothing at all, though a bonus scheme still needs a payroll owner.
Default rung: fund the top pair in the first horizon and nothing else. Move up one rung to referral investment once those two have shipped and offer-acceptance has cleared 70%: until it does, extra pipeline lands on the same leak. Move up again to the blog or talks only when question 9 named the engineers and their protected hours.
Referral investment sits above content on the ratio for a sourced reason: the best-documented practitioner account of channel measurement (Stripe, Greg Brockman) found referrals consistently outperforming careers-page inbound on hire quality. When a team proposes "publish more" as the whole plan, this is the counterweight: ask what a referral bonus and structured ask would cost first.
**OSS-as-funnel is what this order starves**, and it is simultaneously the best-documented channel in the field. Supabase hired its first ~50 substantially from its open-source community with no outbound for two-plus years, and HashiCorp built the community before the company. It loses every efficiency round because it costs maintainer-years before it returns a hire.
Promote it to primary anyway when question 4 says the product genuinely has an OSS core **and** question 12 said compounding. Then fund it properly (paid top contributors, a visible contributor-to-employee path) or not at all. A token OSS effort is the one investment worse than skipping it.
Delete, rather than demote, job-board and generic sourcing spend when question 3 targets senior/staff/principal. Specialist recruiters converge on the finding that this tier is not reached through postings at all, only through community reputation and referrals. And delete any channel whose claims the Step 3 audit contradicts until the operational fix lands.
The ordering is a default, not a law, and it shifts with who executes it. Re-rank against what the Interview told you:
- A company whose engineers already speak at conferences has pre-paid the talks rung.
- An existing well-read blog moves blog maintenance above blog creation.
- Questions 11 to 13 re-rank as described there.
Say which answer moved which channel when you present the result.
## Step 5: Match channels to stage and seniority
This skill splits recommendations by **company stage × candidate seniority**; never hand one channel plan across it.
By stage:
- Early-stage companies run on founder network, referrals, and targeted outbound; content channels lack the compounding time to matter yet.
- Scale-ups are the natural blog/talks/OSS-contribution investors.
- Large companies' brand is mostly a byproduct of scale and published culture artifacts (Netflix's 2009 culture deck is the archetype).
- OSS-first companies treat open source as _the_ funnel, not a supplement.
By seniority:
- Junior and early-career candidates weight compensation transparency, structured onboarding, clear ladders, and process transparency: the Stage-1-style artifacts.
- Senior, staff, and principal candidates respond to technical-depth signals (conference talks, deep architecture posts, OSS maintainership, reputation inside a specific technical community) and are reached through referrals and community standing, not postings.
A plan targeting staff engineers that funds transparency artifacts but no depth channel has matched the wrong row.
## Step 6: Write the plan and validate it section by section
```markdown
# Engineering employer-brand plan: <company>, <horizon>
## Position stage, seniority target, instrumentation baseline, verification-surface findings
## EVP five-value summary; the "what we don't offer" list; claims cleared against the mismatch patterns
## Channel bets 2-4 bets: channel, seniority tier served, owner, protected hours, one signal, review date
## Starved what this plan deliberately does not fund, and the condition that would promote it
## Fix-first operational gaps (process, on-call, reviews) that precede any claim touching them
## Measurement baseline numbers, the thresholds that trigger a re-plan
## Refused tactics this plan will not use (astroturfing, zombie stats, culture claims reality contradicts)
## Review what event forces an early re-plan: a rating drop, a leadership change, a funding round
```
Present one section at a time and get agreement before the next: a wrong EVP caught at section two costs a paragraph; caught at the end it costs the document. A full worked plan for a fictional company, plus a negative example of the funnel-shaped failure, is in [./references/plan-example.md](./references/plan-example.md).
## Measurement
Track offer-acceptance rate, source-of-hire, time-to-fill, referral rate and candidate NPS: behavior, not reach. Two thresholds change the plan rather than tune it:
- Offer-acceptance below ~70%: stop top-of-funnel spend, audit brand-vs-forum mismatch (Step 1's rule, restated because teams forget it once content is shipping).
- Senior time-to-fill well past benchmark (SHRM 2025 cites a 44-day median for nonexecutive roles; senior engineering runs longer): shift budget from content production to referral incentives and direct sourcing, not more publishing.
Never build the business case on the three refused statistics, and label every self-reported case-study figure ("55% decrease in cost per hire") as marketing unless it discloses methodology. The grounded anchors in [./references/published-findings.md](./references/published-findings.md) are what survive an exec who checks.
## Common failure modes
- **Citing the zombie stats.** One un-sourced "72%" in the deck and the exec who checks it discounts the whole plan. Use the tiered anchors instead.
- **Marketing a culture the company doesn't deliver.** Psychological-contract breach drives the exact turnover the brand was funded to reduce, and forums surface the gap within one review cycle.
- **Content volume as the default answer.** Stripe's measured channels favored referrals over careers-page inbound; ask what referrals would cost before commissioning a content calendar.
- **One plan across seniority tiers.** Transparency artifacts recruit juniors; depth and community reputation recruit staff engineers. Question 3 picks the row.
- **Treating candidates as a conversion funnel.** A widely-recirculated practitioner account: a hiring manager asking how to "convert developers into customers" told the candidate everything. Content that reads as recruiting bait fails the audience it targets.
- **Polishing content while the interview process is disorganized.** Process is a brand artifact candidates screen on (24% abandon for it); fix the loop first.
- **Skipping instrumentation.** A plan with no source-of-hire baseline cannot survive its first budget review, whatever it achieved.
- **Token OSS-as-funnel.** An unmaintained "community" repo signals the opposite of what it was meant to; fund it as a primary or close the branch.
## References
### Reference materials
- [./references/published-findings.md](./references/published-findings.md): every figure this skill uses, split by evidentiary strength from publisher-attributed through real-but-soft to self-set baselines; the RJP citations; the caveats to state out loud.
- [./references/stat-debunking.md](./references/stat-debunking.md): where each of the three refused statistics actually comes from, and the exact wording of the grounded alternatives.
- [./references/plan-example.md](./references/plan-example.md): a worked plan for a fictional scale-up, section by section, plus a negative example.
### Hand off to
- samber/developer-relations-skills@engineering-blog-post: to execute a post the plan commissions.
- samber/developer-relations-skills@github-profile-optimization: when the audit flags the code-host profile as a weak verification surface.
- samber/developer-relations-skills@oss-launch: when the OSS-as-funnel branch needs a project actually launched.
- samber/developer-relations-skills@build-in-public: when a founder-led public-narrative channel fits the stage.
- samber/developer-relations-skills@devrel-career: the mirror image of this skill for engineer candidates; route candidates there.
- samber/developer-relations-skills@devrel-hiring: role definitions, job postings and interview loops for DevRel roles specifically; this skill stays at employer-brand strategy altitude.