developer_education_strategy v1.0.0

name: "developer_education_strategy" description: "Decides whether structured developer education is worth building: learning paths, hands on labs, and certification weighed against cost, operating model and staffing, content refresh cadence, and kill rules when completion or adoption stays low. Ships a build or skip worksheet, a cost per completer and cost per activated calculator, and worked plans for a small and a large program. Triggers when someone asks whether to build a developer academy, learning paths, labs, or a certification, how to staff or fund developer education, or why an existing program is not paying off." metadata: { "includeInPrompt": true }

Developer Education Strategy

Purpose

Help a team decide, with numbers, whether to build structured developer education, what shape it should take, and when to shrink or kill it. Most programs fail for plain reasons: no named audience, no owner, content that rots faster than anyone refreshes it, and success counted in enrolments instead of developers who actually use the product. This skill forces the cost, staffing, refresh, and exit decisions before any course gets built.

Three layers exist, in rising cost order. Learning paths are the cheapest: sequenced modules for one role. Hands on labs cost more: sandboxes, reset logic, grading checks, and per learner infrastructure. Certification costs the most and keeps costing: item writing, review, a defensible passing score, delivery, grading or proctoring, retakes, appeals, and recertification. Build them in that order. Never start with certification.

Workflow

1. Score the build or skip worksheet first. Run bin/education_model.py --score-only with the six items (audience, pain, proof, owner, refresh, distribution), each scored 0, 1, or 2. A score under 6 means skip for now. A zero on any item blocks a full build no matter the total, because a course cannot fix a missing audience, owner, or channel. Between 6 and 8, run a small live test first: a workshop plus a docs page, measured for one term.
2. Name one audience per path, by role and job to be done. "Backend developers doing their first integration" is an audience. "All developers" is not. If two roles need the same product, they still get separate paths when their starting point or end task differs.
3. Prove the gap with evidence the team already has. Use support tickets on the same failure, docs pages with high drop-off, failed first API calls, or long time to first successful call. If none of that data shows a repeat failure, the problem is probably product or docs, and education will paper over it at course prices.
4. Design the smallest path that ends in a real product task. Each module ends with the learner doing the thing in a sandbox or their own account: first authenticated call, first webhook handled, first deploy. Borrow the shape of programs that work: Google GEAR pairs instructor led sessions with about 9 hours a week of self paced labs, and AWS Skill Builder builds role based paths out of courses plus hands on labs. The common pattern is practice tied to a real environment, not video alone.
5. Cost it before approving it. Run bin/education_model.py with annual learners, an honest completion rate, an activation rate (share of completers who go on to real product use), build cost, annual staff cost, lab cost per learner, and platform cost. Read cost per completer and cost per activated developer, not total enrolments. Put refresh time inside annual staff cost. A model with no refresh line is flattering itself.
6. Decide on certification separately, and late. Add it only when an outside party needs proof: partners, enterprise buyers, or hiring managers who will trust the credential. Match format to skill. Stripe uses 90 minute multiple choice exams for architect roles and a 6 to 8 hour coding challenge for its associate developer credential, because building skill needs a work sample. AWS Certified Developer Associate shows the going shape for a knowledge exam: 150 dollars, 65 questions, 130 minutes, passing score 720 out of 1000, valid for 3 years. Set a validity period, a retake policy, and an item review cadence at launch, or do not launch the exam.
7. Set the refresh cadence by decay speed, in writing. Labs and code samples tied to fast moving APIs: check on every relevant release, and review monthly. Core path content: review quarterly. Stable concepts: review twice a year. Technical content decays quietly: warnings at a few months old, broken examples and falling pass rates by about six months if nobody checks. The cadence is part of the staffing plan, not a hope.
8. Staff the operating model, not just the launch. Small program: one education lead at least half time plus borrowed expert review. Large program: program lead, educators, a lab engineer who owns sandbox cost and grading, and an exam owner if certification exists. If no named person owns refresh and the numbers, the program is a launch event, not a program.
9. Measure with the Kirkpatrick levels, weighted to the top. Level 1 Reaction (did learners like it) is weak evidence. Level 2 Learning (assessments, lab pass rates) is better. Level 3 Behavior (learners using the product correctly weeks later) and Level 4 Results (activation, support tickets down on the taught task, time to first successful call down) decide whether the program lives. Report activation to leadership as the headline. Enrolments and page views are not results.
10. Apply the kill rules you wrote at launch. Starting thresholds, to adjust before launch and then hold: completion under 8 percent for two terms after one real fix pass means retire or merge the path. Activation near zero means completion is vanity, so rebuild around product tasks or kill. A lab that generates its own support tickets gets pulled until fixed. A certification whose candidate volume cannot support keeping its item bank fresh gets paused. Killing a weak path and folding its best module into the docs is a good outcome, not a failure to hide.

Output Contract

A finished strategy always contains:

• The completed build or skip worksheet with a score, the verdict, and any zero scored blocker named
• One named audience per proposed path, with the evidence that proves the learning gap
• The cost model output: build cost, annual run cost with refresh included, cost per completer, and cost per activated developer over a stated horizon
• A staffing table naming the owner and every recurring role, with time, not just titles
• A refresh cadence per content type, with a named owner and a check method for labs and code
• A certification decision stated on its own: build, defer, or skip, with format, validity, and item review plan if build
• Kill rules with numbers and dates, agreed before launch, covering completion, activation, and lab health
• For a running program, a Kirkpatrick readout that reports Behavior and Results before Reaction

Operating Rules

1. Accuracy rule: every factual claim about an outside program, price, or exam must trace to a verified source (see references/research-brief.md). Never invent numbers, dates, or quotes. Unverifiable means cut it or frame it as a planning input. Thresholds and staffing shapes in this skill are decision rules, and must be presented that way, not as industry averages.
2. Quality over cadence: never recommend building the full program to meet a launch date when the worksheet or cost model says pilot or skip. Report the weak point plainly.
3. Count activation, not applause. A path with high enrolment, low completion, and no product use is a cost, and the strategy must say so.
4. Labs must run real tasks in a real or faithful sandbox. Screenshot tours and typed along code that never executes do not count as hands on.
5. Refresh is a budgeted run cost from day one. If the team cannot fund the cadence its own product release speed demands, shrink the catalog to what it can keep correct. A small correct catalog beats a large stale one.
6. Certification is a promise to strangers. Do not ship one without a defensible passing score method, an item review cycle, a retake and appeals policy, and a validity period.
7. Worked plans for a small program and a large multi path program, with the calculator commands for each, live in references/worked-plans.md. Adapt their inputs, do not copy their conclusions.