01
Name the business problem
Write the adoption, launch, pipeline, or retention problem in one sentence. 'We need more DevRel' is not a problem statement.
DevRel readiness diagnostic
Should you hire DevRel, or fix the journey first?
Use this before writing a job description, appointing an agency, or asking one person to repair every developer-facing problem at once.
Run this on one real developer job
02
Walk the path cold
Follow the developer journey from first impression to a useful result. Do not ask a new hire to compensate for a journey nobody has actually inspected.
03
Choose one owner
For each failure, name the team that can change it. A DevRel hire should not become a polite holding pen for product, docs, and positioning debt.
The diagnostic
The checks that expose the expensive mistake.
01
There is a real developer job to own
DevRel needs a clear first outcome, not a vague remit to create awareness.
- The target developer and their first useful result are explicit.
- The company can name the behaviour it wants to change.
- Leadership agrees what DevRel owns in the first 90 days.
Common failure: The job description says content, community, partnerships, docs, events, social, and growth, because nobody chose a business priority.
02
The core journey is diagnosable
A new DevRel hire needs evidence, access, and a path they can improve.
- The team knows where developers arrive, evaluate, start, and get stuck.
- Activation is defined as more than account creation.
- Product, docs, and analytics owners will share evidence and make changes.
Common failure: DevRel is hired to generate demand while the product team cannot say whether qualified developers reach first value.
03
The company can support the work
DevRel without decision access becomes a content production queue.
- The hire can influence product, docs, and go-to-market decisions.
- There is budget for the work beyond salary: tools, distribution, and technical assets.
- A senior sponsor will unblock cross-functional decisions.
Common failure: The team wants an ambassador but gives them no product access, no technical input, and no authority to change the journey.
04
Success is tied to adoption
Track whether developer behaviour improved, not whether the calendar got busier.
- A first-value event and a return-use signal exist.
- The team can distinguish content reach from qualified evaluation.
- The first 90 days have leading measures and one business-facing outcome.
Common failure: Success is measured in posts, event registrations, and followers while nobody can connect them to developer progress.
What to fix first
Fix the earliest ownership gap, not the loudest request.
If the product is unclear, the quickstart is broken, or nobody can define activation, fix that before expanding the DevRel remit. Hire when there is a specific adoption job, the authority to influence it, and evidence that progress can be measured.
When this is not enough
If you have several plausible problems across positioning, docs, onboarding, content, measurement, and hiring, the Developer Adoption Audit maps the evidence and tells you what to fix before committing to a larger programme.
Questions
Is this only for a first DevRel hire?
No. Use it when resetting an existing programme, deciding whether an agency can help, or clarifying the first 90 days after a new hire joins.
Does a weak score mean do not hire?
Not necessarily. It means the company should narrow the job and remove the obvious blockers first. The right answer can be a short diagnostic or fix sprint before a full-time hire.
What should the first 90 days include?
One developer journey, one adoption outcome, the evidence required to measure it, and the cross-functional changes needed to improve it. Not an activity buffet.
Bring the evidence, not the hunch.
If the problem crosses positioning, onboarding, documentation, measurement, and team ownership, the Developer Adoption Audit joins it up.
Book an Audit Call