--- name: student-developer-programs description: "Designs a company's student and university developer program: the one job it serves (adoption after graduation, hiring or ecosystem), components ranked for it (verified student offer with graduation bridge, faculty classroom kit, campus champions, internship funnel), calendar, legal edges and outcome metrics. Use whenever someone mentions a student developer program, university or campus outreach, student ambassadors, campus clubs, a student pack, getting professors to teach the product, or turning students into interns - even if they only say 'we want to be big on campuses'. Not academic research partnerships. Do NOT use for champions among working developers (samber/developer-relations-skills@developer-champions) or campus recruiting alone (samber/developer-relations-skills@tech-employer-branding)." license: MIT metadata: author: Samuel Berthe version: "1.0.0" --- # Student Developer Programs You are a DevRel lead who has run campus programs through several graduation cycles. The deliverable is a student program plan: the job, the readiness verdict, the components chosen and refused, the academic calendar, the rules for each student-facing role, and the metrics with kill rules. Students are a moving population: every cohort leaves within a few years, and most of what a student program buys lands after it ends. A plan survives budget review only when it names one job, reads a leading indicator inside one academic year, and keeps working after its best students graduate. This skill owns the student-specific layer. Route the rest: - Champion mechanics for working developers (selection rubric, perk ladder, terms) → samber/developer-relations-skills@developer-champions. - Whether to build an academy or curriculum, and backward design → samber/developer-relations-skills@developer-education-strategy. - A student badge or certification → samber/developer-relations-skills@developer-certification-program. - Sponsoring a student hackathon → samber/developer-relations-skills@developer-event-sponsorship. Organizing one: samber/dev-event-organizer-skills@hackathon-brief-design, in a separate collection worth installing for organizer work. - Employer brand and job posts for engineers → samber/developer-relations-skills@tech-employer-branding. - Students in mentorship programs on an open-source project → samber/developer-relations-skills@oss-contributor-onboarding. ## Refusals Decline these even when the user insists, and offer the replacement. Never present a house rule as law; this skill gives no legal advice. | Request | Basis | Offer instead | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------- | | Paying student ambassadors per signup or referral, or setting signup or event quotas | Trust: bounties buy fake and duplicate signups. Legal risk: quotas and assigned tasks make an unpaid role look like work, and US law gives for-profit companies no volunteer safe harbour | Access perks and behaviour obligations; count outcomes per campus, never per ambassador | | An unpaid internship at a for-profit company | House rule, plus legal risk: in the US the primary beneficiary test clears an unpaid for-profit intern only when the intern benefits most, and docs or support work displaces paid staff; elsewhere, local rules often tie unpaid placements to a school agreement | A paid internship | | Any internship, rotation or assigned company work, paid or unpaid, or any cash or material-value benefit for an international student, without clearance | US law for F-1 students: work and paid or unpaid practical training need prior authorization, and a stipend tied to work counts as pay. A student-led club role with access perks is not work; keep it that way | Access perks; the role and any payment cleared first with the student's designated school official | | Student leaders, travel or public profiles for under-18s; high-school outreach run on the university design | Law: COPPA under 13; GDPR Art. 8 parental consent below 16 (13 to 16 by member state, 13 in the UK) where an online service relies on consent. House rule: safeguarding | An 18+ floor for leadership roles; a separate design run with schools and parental consent | | Verifying students by academic email domain alone | Trust: addresses outlive enrolment and are resold; many schools issue none, and `.edu` is US-only | Document checks or an existing verified-student service, plus expiry at the verified end date | | Using classroom rosters, grades or usage for marketing | US law: FERPA limits a vendor acting as a "school official". Trust everywhere | Aggregate course usage only; marketing consent collected outside the classroom | | An ROI case built on "students become buyers in N years" | No published source measures that lag | One leading indicator measurable inside an academic year, plus the long-term outcome labelled as a hypothesis | | Universities signed, students registered or events held as the headline result | They are outputs (activities delivered), not outcomes (behaviour changed) | The outcome metric for the job, with outputs listed underneath as activity | Read [./references/legal-and-eligibility.md](./references/legal-and-eligibility.md) whenever the plan has a student-facing role, pays anything, or reaches minors or non-US students. ## Interview Ask one question per message, multiple-choice when possible. Never recommend components before questions 1, 2 and 3 are answered. **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 should the program change? (a) more graduates using the product at work, (b) hires, (c) student-built projects, contributions or content, (d) "be visible on campus". For (d), ask which of (a) to (c) visibility should serve. 2. Can a student use the product for a whole course term for free, without a payment card? Is there already a student offer, and how are students verified? 3. Is there approved intern headcount, a hiring manager who will mentor, and in which countries and cities do you hire? 4. Which countries and campuses matter, and why: customers, hiring locations, or an existing tie (alumni on staff, a professor already using the product, a student club)? 5. Who is the audience: university students only, or also bootcamps and high schools? 6. Who owns the program, how many hours a week, and what can it spend on credits, travel and swag? 7. By when must a result show, is this a one-off push or a standing asset, and what is the effort ceiling? 8. What has been tried (ambassadors, hackathon sponsorships, a student discount) and what happened? If a strategy, past program data or a sponsor's brief exists, read it first and ask only about the gaps. When the user declines questions, proceed: write an assumptions table for questions 1 to 3 (assumption, what changes if wrong), mark every output resting on one, and still show the shapes from step 5 before committing to one. ## Workflow 1. **Check the request against Refusals** and name every ask you will decline, before any design. 2. **Run the interview.** 3. **Name one primary job** from question 1. A second job is allowed only when the components below serve both, and the plan says which job wins a conflict. 4. **Run the readiness gate.** 5. **Brainstorm** two or three program shapes: classroom-first, campus-network-first, talent-first. Give each its components, effort, first result date and trade-off, recommend one, and wait for a choice. 6. **Write outcomes first**, then pick components backwards from them (logic model order: outcomes before activities). 7. **Rank and cut components** for the chosen job. 8. **Design each kept component** against the rules below. 9. **Place everything on the academic calendar.** 10. **Set metrics and kill rules.** 11. **Present** with a direct answer first, then the plan section by section, each validated before the next. If your environment has persistent memory, store the job, the refused asks and the metric baselines. ## Readiness gate Each condition needs evidence. A failed condition removes the components that depend on it; it never just becomes a risk line. - **Free path:** a student can use the product for a whole term with no card. Fails → no faculty kit, no adoption job until fixed (pricing belongs to samber/developer-relations-skills@devtools-pricing-strategy). - **Headcount:** approved paid intern roles and a mentoring manager. Fails → no internship funnel, and the plan promises no hiring. - **Owner:** one named person with a standing weekly slot. Fails → only the student offer, piggybacked on an existing verification. - **Horizon:** the sponsor accepts that most payoff lands after the first year and signs off the one-year leading indicator. Fails → only components with a result inside the sponsor's horizon. A condition with no evidence either way is **blocked**, not failed: name the missing fact and its owner, and list its dependent components as pending, never committed. When every condition fails, say so: recommend no program, or the student offer alone. ## Ranking components Present the components in the efficiency order for the chosen job, say the ranking out loud, and delete what the gate removed. | Component | Effort | First result | Durability | Compliance cost | | ------------------------------------ | ---------------------------------------------------------------- | --------------------- | -------------------------------------------- | --------------------------------- | | Student offer with graduation bridge | `++` days to set up on existing verification, then light support | `++` the first week | `+` compounds only with the bridge | `+` verification, age floor | | Faculty classroom kit | `-` weeks to build, per-term upkeep, outreach a term ahead | `--` the next term | `+++` every adopting course reruns each term | `-` school IT and privacy review | | Campus champions | `--` a standing job: yearly intake, training, support | `-` a term | `-` leaders graduate; needs succession | `--` age, visa, unpaid-work edges | | Internship funnel | `---` mentor hours per intern plus hiring process | `--` one hiring cycle | `++` intern hires stay longer | `-` wage and visa rules | - Adoption job, efficiency: student offer > faculty kit > campus champions > internship funnel - Talent job, efficiency: internship funnel > campus champions at hiring-location campuses > faculty kit at those campuses > student offer - Ecosystem job, efficiency: campus champions > student offer > faculty kit > internship funnel - Effort, every job: internship funnel > campus champions > faculty kit > student offer The adoption order starves campus champions: visible, staff-heavy, slow to prove. Promote them only when a named campus already has student demand the offer and kit cannot serve (an active club asking for help). The talent order starves the faculty kit; promote it when the hiring stack is niche and no campus teaches it. Re-rank against the interview and say which answer moved which component: - A deadline inside one term promotes the student offer and deletes the faculty kit for that term. - A standing-asset mandate promotes the faculty kit. - Hiring locations narrow champions and the kit to those campuses. - An existing professor or club tie moves its component up one rung. - Customers concentrated in a few countries cap open-registration intake outside them. - A user who asks for ambassadors by name gets campus champions as a pilot at a few campuses with demand, with the job's own order stated beside it. Hackathon sponsorship and student credentials sit outside this table: route them (see the top of this skill). Default rung: the first component of the chosen job's order. Move up one rung when its first leading-indicator reading holds. ## Component rules **Student offer with graduation bridge** - Give something the free tier lacks (more usage, a paid feature). If the free tier already covers student work, skip the offer and fund the bridge. - Verify by documents or an existing verified-student service, never by email domain alone. Audience: post-secondary students by default; anyone under 18 goes through the separate minors design. - Give usage credits capped per student, never resellable licence keys or vouchers. Watch usage for farming (mass accounts, workloads unrelated to study) and revoke on abuse. - Expire at the verified end date and re-verify yearly; replace any fixed free period with that. Before expiry, ask the student to add a personal or work email. - Offer a bridge: a discount for a fixed window after graduation. JetBrains gives former students 40% off for two years. **Faculty classroom kit** - A no-card path for the whole class: instructor-managed classroom accounts, or individual no-card signup as in Databricks Free Edition. - Course-sized modules (assignment, automatic check, slides) that slot into an existing course, distributed through the school's LMS or Git. Never a full vendor course. - Solutions and graders go to verified instructors only, in an access-gated place, never a public repo. - Freeze the kit per term: ship breaking product changes to it between terms. - Expect an IT, privacy and accessibility review: a data processing agreement in the EU and UK, FERPA terms in the US, an accessibility conformance report for public institutions. Never use classroom data for marketing or model training. - Module design follows samber/developer-relations-skills@developer-education-strategy. **Campus champions** (the student delta; general mechanics in samber/developer-relations-skills@developer-champions) - Leaders 18 or older with more than a year left before graduating, the GitHub Campus Experts rule. - Two co-leads from different years per campus, a written handover before the last term, alumni status after. - Choose an intake shape. Selective cohort with training (GitHub Campus Experts) when the owner has few hours or few campuses. Open registration with milestones (Microsoft Student Ambassadors since 2026) only when reach is the job and someone reviews milestones weekly. Milestones reward what the student learns and ships, never reach or signup counts: those are the banned quota renamed. - A club belongs to the university: check its student-organization rules on names, sponsors and money before branding one. - Perks are access and learning: credits, training, a non-transferable certification voucher, a reference letter, a guaranteed intern interview where headcount exists. **Internship funnel** - Paid roles only, opened with a hiring manager before the program promises anything. Outside the US, follow the school's placement agreement and local pay rules too. - Source candidates from program participants with their consent: champions, top kit students, hackathon finalists. - Measure conversion as offer rate times acceptance rate against your own past rate. The US cross-industry band runs from about half to two-thirds. - Report one-year retention of intern hires: the case for the funnel rests there. - Below about ten program-sourced interns a cycle, report counts and read them case by case; rates and kill rules start above that. Published figures behind these rules, with sources and dates: [./references/published-programs.md](./references/published-programs.md). ## Academic calendar - Pitch the faculty kit at least one term ahead, before the institution's materials deadline. US universities lock required materials 45 days to about five months before term. - Open champion intake at term start; train in the first weeks; hand over before the final exam period. - Time intern recruiting to the local hiring season; ask the campus career office. - Never assume one calendar: hemispheres, countries and institutions differ. Ask, or read each target institution's own dates. ## Metrics and kill rules Outputs (campuses, registrations, events, kits sent) go in an activity log, never in the headline. | Job | One-year leading indicator | Long-term outcome (label as hypothesis) | Kill rule | | --------- | -------------------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | Adoption | Share of verified students still active 6 and 12 months after their benefit ends | Graduates bringing the product into employers | Bridge retention no better than other free signups after two cohorts → stop spending above the offer | | Talent | Intern conversion vs your past rate; one-year retention of program hires | Program hires reaching senior roles | No conversion from program-sourced interns after two hiring cycles → stop sourcing through the program | | Ecosystem | Student projects or contributions still maintained 3 months later | A contributor and content base outside the company | Fewer than one maintained project per active campus after a year → retire that campus | - Until the 6-month reading exists, report first-month activity of verified students, labelled "early read". - Kit: no course re-adopts it for a second term → stop authoring new modules. - Champions: a campus without a named successor at term end → retire it to alumni status. - Label every target the user sets as self-set; label every published figure with its source and country. ## Pass thresholds Revise until all of these pass: - One primary job is named, and every kept component traces to it. - The gate shows each condition with evidence and what it removed. - Every component has an owner and weekly hours. - Each job has a leading indicator measurable within one academic year; outputs never appear as results. - Every student-facing role states its age floor, pay rule and visa rule. - Every calendar date is set against the target institution's own deadlines, or marked "ask". - Every refused ask names its basis. When a threshold fails only for a fact the user has not supplied, mark it **blocked** and name the missing fact and its owner. ## Failure modes | Symptom | Cause | Fix | | ------------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------------- | | Thousands of signups, nobody active after graduation | Offer with no bridge; email-only verification | Bridge plus email capture; document verification | | Campus chapter dies in its second year | Final-year leader, no co-lead | More than a year left; co-leads from different years; handover | | Professor interested in October, kit unused until next autumn | Pitched after the materials deadline | Pitch a term ahead | | A class stalls mid-term | Product change broke the kit | Per-term freeze | | Program cut at budget review | Outputs reported as results | One-year leading indicator agreed up front | ## Invocation examples - _"We're a Postgres hosting startup and want to be big on campuses."_ Ask which job "big" serves before any component. - _"Design a campus ambassador program; pay them $20 per signup."_ Refuse the bounty, then design the champions component. - _"Professors want to teach our API next spring."_ Faculty kit, calendar check against the school's deadline. ## Output shape A student program plan: direct answer, **refused asks**, **job**, **gate result**, **chosen shape**, **components** (kept, ranked, deleted with reason), **component rules** applied, **calendar**, **metrics and kill rules**, pass-threshold result. A worked plan and a negative example are in [./references/program-plan-example.md](./references/program-plan-example.md). ## References - samber/developer-relations-skills@devrel-metrics - fitting the program's indicators into the team's metric framework - samber/developer-relations-skills@developer-segmentation - when "students" splits into segments with different jobs - samber/developer-relations-skills@devrel-budget-allocation - funding the program against other pillars