Lesson 4 of 4 · 60 min

Defend a DevRel portfolio with evidence

Present one artifact, its verified result, and a bounded improvement plan.

A DevRel portfolio should make technical work and its effect inspectable. A list of talks or follower counts describes activity. Select one artifact and show what a developer can do with it, how you verified it, what feedback changed it, and what evidence suggests it helped the intended audience.

Separate your contribution from shared work. You may have written the tutorial, while an engineer supplied the API contract and a community member found a setup defect. Explain these roles. The portfolio becomes stronger when it shows how you work with technical reviewers and users, not when it presents every outcome as an individual achievement.

Use appropriate measures. For a workshop, completion and transfer tasks can show learning. For documentation, successful task completion and reduced specific friction can be useful. For open source, a merged contribution or a shorter path from issue to accepted patch can matter. Stars and impressions can help describe reach, but they do not prove these outcomes.

State source and measurement limits. A survey response is self-reported. A small cohort is not the entire developer market. A public employer role description supports the importance of technical content, but it does not prove that your proposed interview prompt is used by that employer. This evidence discipline should appear in the portfolio itself.

Worked example

A fictional candidate presents a local event-handling tutorial. Its fixture produces two effects from three deliveries. The candidate added a conflict-payload exercise after observing learners deduplicate by value. In a workshop of 30 attendees, 24 completed the guided example and 15 correctly answered a new identity scenario. Ten answered a follow-up survey, and six reported using the technique elsewhere.

The candidate reports those counts with denominators and does not claim six production deployments caused by the workshop. The next improvement targets the gap between 24 completions and 15 successful transfers: add a second contrasting example and observe whether learners can explain the identity rule before coding.

Build a portfolio evidence card

A reviewer should be able to inspect one artifact without reconstructing your whole career. Choose a tutorial, sample, workshop, or contribution with a clear developer task and a visible result. Include its maintenance state so an old successful launch is not mistaken for a currently verified path.

code

1Artifact: local duplicate-delivery tutorial2Audience: HTTP-literate developers new to effect identity3My contribution: fixture, explanation, transfer exercise, revisions4Reviewers: engineer checked contract; learner reported setup issue5Verified result: declared local fixture, with actual check record linked6Observed learning:24guided completions;15correct transfer answers7Reported later use:6positive reports among10survey respondents8Limit: no causal production-adoption claim9Next change: contrast event ID with purchase identity earlier

The figures are fictional teaching inputs. For a real portfolio, link actual permitted evidence and distinguish a completed check from a proposed check. If the artifact was collaborative, state what you wrote, what others supplied, and who verified behavior.

Make the cohort relationships explicit

Assume all thirty attendees had the full follow-up window, all fifteen transfer successes came from the twenty-four guided completers, and the six positive later-use reports came from the ten respondents. Guided completion is 24/30=80 percent. Transfer among guided completers is 15/24=62.5 percent, while transfer among all attendees is 15/30=50 percent. Survey coverage is 10/30, about 33.3 percent. Positive reports among respondents are 6/10=60 percent.

Each ratio answers a different question. Do not turn 60 percent of respondents into 60 percent of attendees. The observed positive reports are six people, with twenty attendees not represented in the follow-up survey. The later use may be exploratory rather than production, and prior intent can affect attribution.

Evidence	Supports	Does not establish
Correct local fixture	Behavior in the checked sample	Live integration reliability
Guided completion	Procedural success under instruction	Independent transfer
Fresh transfer answer	Reasoning on that changed case	Every production decision
Self-reported later use	Respondent's stated application	Causal production adoption
Merged contribution	Accepted project change	All subsequent project growth caused by it

This table gives the portfolio a useful shape without requiring every metric to be available. Missing evidence is an opportunity for a better next check, not permission to fabricate a number.

Connect feedback to a revision

The gap between twenty-four completions and fifteen correct transfers suggests a specific teaching issue. Inspect wrong answers before selecting a fix. If learners deduplicate by amount, add distinct IDs with equal values. If they confuse event identity and purchase identity, add two different events describing one purchase. If they overclaim restart safety, add the external-effect uncertainty schedule.

Then assess with another fresh case, not the same answer learners just memorized. A revised lesson can improve performance on one case without proving broad mastery. Report the narrower result and continue observing relevant transfer.

Feedback can also reveal product friction. If correct reasoning is high but setup repeatedly fails at token scope, the next action may be a verified quickstart repair rather than more conceptual teaching. Use the evidence to decide whether the barrier is content, environment, product behavior, or audience fit.

Propose a first-month plan that produces evidence

For the supplied outdated quickstart, start by reproducing its path on the stated supported version. Record which steps fail and why. Repair the owning example and instructions together, get a technical review of permission semantics, and verify a fresh run. That is a concrete initial deliverable.

Next, observe a small cohort attempting the corrected path with defined success and failure events. Collect safe reproducible friction rather than only satisfaction. Define activation as a meaningful first result and record response/follow-up coverage for any later survey. The first report should say what changed, what was observed, and what remains unknown.

Choose a named owner and review point for the artifact. Posting frequency can support distribution, but it does not repair a broken first-use path by itself. If the program's explicit purpose is awareness, reach remains relevant; the plan should still avoid mislabelling reach as activation.

Misconceptions and a second exercise

One misconception is that a portfolio needs large numbers to be credible. A small artifact with exact evidence can show more technical judgment than a large unsupported reach claim. Another is that every improvement must be attributed solely to the advocate. Technical review, product changes, and community feedback can all contribute.

Exercise: your tutorial received ten thousand views, but only twelve people attempted the instrumented exercise and eight completed it. The viewing and exercise populations cannot be fully linked. Write a defensible report. State the reach count and separate observed exercise counts, explain the linkage limit, and avoid calculating a conversion rate as if every view were a unique eligible learner. Award one point for each count, one for the identity/population limit, and one for a next measurement that connects the intended user path.

A strong portfolio defense shows that you can build, explain, verify, listen, and revise. Its claims remain credible when the interviewer asks how you know, who else contributed, or what would change your next decision.

Exercise and solution

The interviewer asks for a first-month DevRel plan. Inputs: one outdated quickstart, repeated scope errors, and no verified adoption data. The model plan repairs and tests the quickstart, collects a small set of reproducible onboarding observations, defines a useful activation event, and publishes a bounded report of what changed. Award one point per action and one for naming an owner and review point. A plan centered only on posting frequency misses the supplied problems.

Interview probe and wrap-up

What would you stop doing if the program has high reach but no useful activation? A strong answer investigates audience fit and onboarding friction, then changes the content or distribution based on evidence. Follow up with a program whose purpose is awareness rather than activation. A weak answer treats one metric as universal. A portfolio should show that you can build, explain, measure, and revise technical work in response to real developer needs.

Sources

docsGitLab Developer Advocacy program and measureshandbook.gitlab.com docsGitLab Developer Advocate rolehandbook.gitlab.com docsGitHub open-source contribution guideopensource.guide

Checkpoint

15 transfer successes are among 24 guided completers. Transfer rate among completers?

A60 percent.B50 percent.C62.5 percent.D80 percent.

Checkpoint

Six of ten respondents report later use; all ten are among thirty attendees. What report is supported?

ASix of thirty is the complete adoption rate because nonresponse counts as no use.BThe 60 percent respondent rate establishes eighteen users among all thirty attendees.CSix reports establish six deployments caused by the workshop.DSix positive self-reports, with 10/30 response coverage and unobserved use among nonrespondents.

Checkpoint

Learners complete the commands but choose amount rather than purchase ID as the effect identity. Which revision addresses that observed gap?

AAdd more copies of the same repeated-ID example with its expected total visible.BAdd an equal-value/distinct-ID contrast, inspect reasons, then reassess with a fresh case.CAdd an advanced SDK installation section before the existing example.DIncrease the event batch size while keeping every amount and ID paired exactly as before.

Checkpoint

Ten thousand page views cannot be linked to twelve exercise attempts. Which report preserves what is measured?

AReport reach and exercise counts separately, state the linkage limits, and avoid a conversion claim.BReport 0.12 percent learner conversion because both metrics came from the same content campaign.CTreat all views as distinct eligible learners after removing obvious crawler traffic.DTreat twelve attempts as twelve completions because users reached the exercise page.

Checkpoint

A quickstart has a reproduced failure and the team has no activation definition. Which first-month plan has a sound evidence path?

AStart with a larger launch campaign and use traffic growth to decide whether the quickstart repair is necessary.BDefine activation as newsletter signup, then keep the current quickstart unchanged because it serves a later stage.CRewrite the full documentation system before isolating the failed step or defining what first success means.DRepair and verify the quickstart, collect specific friction, define a useful first outcome, and review the evidence with an owner.

Can you defend an artifact with correct cohort relationships, contribution boundaries, and a next step tied to observed developer friction? State the relevant identifiers, failure boundary, and evidence in your own words before selecting your confidence.

Not yetGetting thereConfident

Sources

Free to read · better with Enzo

Learn it with Enzo

Save your progress, answer the checkpoints, and let Enzo quiz you on what you just read.

Continue with Enzo Sign up free