Devrel Hiring

DevRel Hiring

Build the four artefacts a hiring manager needs to recruit into a DevRel role with the same rigour the field's own hiring research recommends: a role scorecard and posting, a structured interview loop with question bank, a portfolio-and-work-sample evaluation, and a 30-60-90 ramp plan.

DevRel has no standard job description or career ladder (Chris Aniszczyk, CNCF CTO), and its own hiring literature documents two named failure patterns in postings written without this discipline - see Reading the answers. That absence is the reason to build these four artefacts deliberately rather than adapt a generic engineering or marketing hiring template.

Out of scope, hand off instead:

• Where DevRel reports and how the team is shaped - samber/developer-relations-skills@devrel-team-structure decides the org before this skill recruits into it.
• Coaching the candidate - samber/developer-relations-skills@devrel-career is the mirror image of this skill, built for the person being evaluated.

If the user is job-hunting rather than hiring ("how do I prep for a DevRel interview", "is this posting worth applying to"), say so in one line and point them at devrel-career.

Interview

Ask one question at a time, multiple-choice where possible. Skip anything already answered. Questions 8-10 re-rank the artefacts below before any is built - ask them before producing anything.

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. Company type: (a) early startup, pre-seed-A, this will be a team of one (b) growth/scale-up, B-D (c) big-tech enterprise (d) OSS-first company or foundation.
2. Role target: (a) developer advocate, outreach-focused (b) developer advocate, product-focused (c) community manager (d) developer educator (e) DX engineer (f) not sure - recommend one from the funding driver.
3. What funds this role - the driver behind the budget: developer adoption, sales enablement, developer enablement, product input, ecosystem/partnerships, contributor community, or employer branding?
4. Go-to-market motion: sales-led B2B, product-led (PLG) B2B, B2C/individual-facing, or OSS/foundation with no purchase gate.
5. Coding-depth requirement: does this role need to ship SDK samples and review API design, or is the bar public communication with only light code?
6. Team stage: first DevRel hire with no incumbent to calibrate against, or a repeatable hire with existing top performers to profile from?
7. Compensation stance: will you publish a range in the posting, and do you know your hiring jurisdiction's pay-transparency requirement?
8. Deadline: this month, this quarter, or no hard date?
9. One-off hire or the first of several where the scorecard and question bank get reused?
10. Effort ceiling: how many interviewer-hours per candidate, and is there a recruiter or a trained panel?

Reading the answers

• Q1 sets the bar and the portfolio weighting - load references/company-type-and-driver-lookup.md. A startup hires a generalist who justifies the function's own existence; big tech anchors the role to its engineering levelling scale; an OSS/foundation role screens on contribution history, not communication polish.
• Q2 + Q3 decide what the posting is screened on - see references/company-type-and-driver-lookup.md for the per-role requirement table. A candidate who cannot say which sub-role they target is applying to all and matching none; the same is true of a posting that cannot say which sub-role it needs.
• Q3 + Q4 decide the pillar mix and therefore the metric the role is measured on: sales-led promotes advocacy plus sales enablement; PLG promotes enablement plus product input; B2C promotes community plus reach; OSS/foundation promotes community plus advocacy.
• Before drafting the posting, self-audit it against the field's two named failure patterns (Joe Nash, DevRelCon 2021 - the same taxonomy devrel-career teaches candidates to detect from the outside):
• Gatekeeper - describing an impossible person: a full engineering career across several stacks plus OSS contribution, technical writing, community building and event organising, advertised at entry pay.
• Pit trap - "founding DevRel, no background required" that actually expects one person to cover docs, SDKs, community, support, sales engineering, and training with no resources, no ladder and no stated goal.
• Both share three symptoms: off-core skills emphasis, a tactics list with no stated outcome, and levelling that is inconsistent with the pay. A posting failing any symptom needs a rewrite before it goes out, not after it fails to convert.
• Q6 decides the candidate profile. First hire: a builder who can justify the function's existence without an incumbent team, similar to a company's first sales hire - weight self-direction and breadth over specialised depth. Repeatable hire: profile from the org's own top performers on the pillar this role actually owns.
• Q7 triggers the compensation gate in the Quality gate below - never invent a jurisdiction's legal requirement; confirm current pay-transparency rules for the hiring location before publishing.
• Q8 promotes the fast-acting options: a this-month deadline promotes reusing an existing question bank and a shorter loop over designing a new custom work sample from scratch.
• Q9 decides whether the work sample stays thin. One-off: design it once, cheaply. Compounding: the frozen rubric and question bank serve every future hire in this pillar, which promotes building both properly first.
• Q10 deletes loop stages rather than reordering them. Under a handful of interviewer-hours per candidate: cut to a scorecard, one structured conversational round, and the portfolio evaluation; skip a live work sample entirely rather than running it unscored.

Workflow

Produce the four artefacts in order. Deliver each one, validate it with the user, then move to the next.

1. Run the Interview. State the role and pillar-mix recommendation in one short paragraph the user can veto.
2. Artefact 1 - role scorecard and posting. Build from references/company-type-and-driver-lookup.md and references/scorecard-and-posting-template.md:

• a one-sentence mission naming the funding driver from Q3
• 3-8 measurable outcomes ranked by importance and quantified (e.g. "cut top-three onboarding support threads 25% via a shipped friction-log fix", "40 accepted CFPs sourced from the community in year one"), never vague responsibilities
• 5-7 competencies weighted per the role and company type from Q1-Q2
• run the gatekeeper/pit-trap self-audit above before publishing

1. Artefact 2 - interview loop and question bank. Build from references/interview-loop-and-question-bank.md:

• pick 3-5 formats from the field's verified set (presentation round, content take-home, coding take-home, technical self-rating, conversational rounds, DevRel-opinion round, founder/exec round at startups) - there is no standard loop, so choose formats that actually test this role's pillar mix, never the whole set by default
• place the portfolio evaluation (Artefact 3) early, before any new work is requested of the candidate